From nobody Sat Feb 7 08:07:11 2026 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 195B52FE582 for ; Tue, 27 Jan 2026 16:30:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769531459; cv=none; b=WZogyC+QwFuSohCE90vaxihHuPYBrRsalXx/DL0PuSzYnILysXjY6u16DghWKOJHOnCGEvuplaRuN1IwF9tfh7tmhdODigBkfhjziO+alYFyFPCnPsim3281k4XPpOLLWuh4deMQ+NXVVtUnSzUwK/sX6tbEwHnpocZejd1escE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769531459; c=relaxed/simple; bh=Ni9cZG+geyV7R5ptEtpT9bf+Z96YeRXMlBWy8S2AVbk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=ka3PNoTMwiVzKK4wRIKkCdn4v645TwCf/ffrLrgPDM5m1CE5sv+XvJVuAW+iPphgo7F495FJ8ciZX7qWp77LUJebtP1k8cTt+1hi0M1BpAQ+MnJTX54HZSG9FCrMbtbNchtA4L8PxxE0mjcQV12c1cBaByf8X02dTXi4aiZH2T0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gr+9OK31; arc=none smtp.client-ip=209.85.128.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gr+9OK31" Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-7944693b824so36729587b3.3 for ; Tue, 27 Jan 2026 08:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769531457; x=1770136257; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=r3HHYD4aeaQa5ff4aHF396cehTuEDTmWYhC92tg8m6k=; b=gr+9OK31GZpDs6hmjZjiOxTWfr5wTUJofTfFpb4sgkfMfzWIGBVfNMumd1ah7BTx0O OCnBkpVsRZcZB+nka2MD9cCazlEjbT4gjUAgH8sHQHGyVYl/+g496KF2HGwIk9a4ZDK2 OT1AMWXof/kOQh/VWCClh69YgU4NyMeAzRZN1RfPVSvx5DUBTgTv0kD24TPPD1EwWh4r rL864Xj6oVN0jnOiCnewhZDOfQ9bDU95SYJfU04O+AjfjR0CMp9oSYt18JDvZTkb0SQJ 2oS6vRQguemOHixU947P0FzkD/Noz7qh+nwb0sByOLG1RwaytmyILkKb63KHm+cRsFA/ Bs4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769531457; x=1770136257; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=r3HHYD4aeaQa5ff4aHF396cehTuEDTmWYhC92tg8m6k=; b=qQ39DrYjB8riXejBkEpqzlCU8VHYVFjzi6lmeB+5nS0Y+V8CBnmYjT/4VxM857RAxe Ot8KYYsOOZlRGXMdC6P4F8iRueswWeBU5Y0qBRi30v0lPh2sjyiOIUYB8eaH876A6KeT vvBY3SRiI9IV3mKxMlvbGVJeN6Qtbfbsme+GoxqUGFALrBmhP689WTSCcK3B2B3tUy27 uPqKRHGQN0Ea/umJK62aeD/xGYvJKxbIxz8jM3jIGQpF3i8zDzotu9qV08tDxCQ/k4GJ efwX8vtUZjSlvlGaPw/TX1pFxp73DkJ3zsxt5+XDmwOHe+VA6qHLvePXBNgy1LGqo5PD JMzQ== X-Forwarded-Encrypted: i=1; AJvYcCU9UJuxVukqBY7weUma8sSjtgZXZ9YelLzUSPwmAh1V2RHwkuNhtEdjamJ2EgVsqXEskINIpb7dJ9jGNwg=@vger.kernel.org X-Gm-Message-State: AOJu0YxZIq8apKxwGcluLGhRf2HbBw5ha9unsfZL4noqFPuyT6kSyvat QbxPa2gvXaNFo6lAt7eup6PUC3B+6+7oYnQyWAgXZrSZSOfAer2YSa9o X-Gm-Gg: AZuq6aJ8kYao3B+IoZk/hA6whMCqU4f0S+x9cB6w2nR8IIE2DskPjFFhqHbJooU2+7+ OosKaCrrFyRpZSoXXy6oc0p1AiI+B6FCZul8m0V3mBoCSjcuAmYk0GLiaOAdm2fGgSsaI5me5Vj AqvrM0LGdo4WFECBlOH73XP+yP6Box7sHLyfRdwUr6ns+Wg1x63mGb5hXrX+JWJvyOC5yCa9maw Yq7o1ij20uun1PsLJaydJ7HL6ReTTpsKJXjyrF7/fVogXtC8szq0GSube0clzUHtJObjzO+EYeq QAvEA7u6mG/aqE3uD3mFF8IjPOdFzea3IN6wd0MvXlTuN8gOrfb32bhX+jf7zsX1CDfgpoOyiTL JKgMR7bGqXEJWg+mmlQfAO7qq23WgUVXZJidRecpY8FwW3bruXPSx0aZww5whI+qDHKmSHNgRXa z9CkzBPGI= X-Received: by 2002:a05:690c:6902:b0:78c:672:9b40 with SMTP id 00721157ae682-7947ac5b3f2mr16260637b3.55.1769531456630; Tue, 27 Jan 2026 08:30:56 -0800 (PST) Received: from localhost ([2a03:2880:25ff:e::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7943b2a2cf6sm63595157b3.33.2026.01.27.08.30.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 08:30:55 -0800 (PST) From: Daniel Zahka Date: Tue, 27 Jan 2026 08:30:55 -0800 Subject: [PATCH net-next] selftests: drv-net: psp: fix test flakes from racy connection close Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260127-psp-flaky-test-v1-1-13403e390af3@gmail.com> X-B4-Tracking: v=1; b=H4sIAD7oeGkC/x3MQQqDMBBG4avIrDuQRAzSq5Qugv3VQUlDJhSL5 O4Gl9/ivZMUWaD07E7K+InKNzbYR0fTGuIClk8zOeO8sc5z0sTzHrY/F2hhBG97hKEf/UQtShm zHPfwRRGFI45C71ov306BlGoAAAA= To: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan , Willem de Bruijn Cc: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Zahka X-Mailer: b4 0.13.0 There is a bug in assoc_sk_only_mismatch() and assoc_sk_only_mismatch_tx() that creates a race condition which triggers test flakes in later test cases e.g. data_send_bad_key(). The problem is that the client uses the "conn clr" rpc to setup a data connection with psp_responder, but never uses a matching "data close" rpc. This creates a race condition where if the client can queue another data sock request, like in data_send_bad_key(), before the server can accept the old connection from the backlog we end up in a situation where we have two connections in the backlog: one for the closed connection we have received a FIN for, and one for the new PSP connection which is expecting to do key exchange. From there the server pops the closed connection from the backlog, but the data_send_bad_key() test case in psp.py hangs waiting to perform key exchange. The fix is to properly use _conn_close, which fill force the server to remove the closed connection from the backlog before sending the RPC ack to the client. Signed-off-by: Daniel Zahka --- The data_send_bad_key() test case has been flaking in automated testing. The root cause is actually some racy connection setup/teardown logic between the client and server in the preceding test cases. I have detailed the exact circumstances for the test failure in the commit. To reproduce the issue deterministically, I inserted a sleep into the psp_responder.c conn clr handler if (cmd("conn clr")) { if (accept_cfg !=3D ACCEPT_CFG_NONE) fprintf(stderr, "WARN: old conn config still set!\n"); accept_cfg =3D ACCEPT_CFG_CLEAR; send_ack(comm_sock); + sleep(1); } which produces the following error just running two tests: 1..2 =20 ok 1 psp.assoc_sk_only_mismatch = =20 # Exception| Traceback (most recent call last): # Exception| File "/data/users/dzahka/psp-flaky-test/tools/testing/selft= ests/net/lib/py/ksft.py", line 319, in ksft_run # Exception| func(*args) =20 # Exception| File "/data/users/dzahka/psp-flaky-test/./tools/testing/sel= ftests/drivers/net/psp.py", line 420, in data_send_bad_key # Exception| tx =3D _spi_xchg(s, rx) # Exception| File "/data/users/dzahka/psp-flaky-test/./tools/testing/sel= ftests/drivers/net/psp.py", line 65, in _spi_xchg # Exception| tx =3D s.recv(4 + len(rx['key'])) # Exception| File "/data/users/dzahka/psp-flaky-test/tools/testing/selft= ests/net/lib/py/ksft.py", line 258, in _ksft_intr # Exception| raise KsftTerminate() # Exception| net.lib.py.ksft.KsftTerminate = =20 # Stopping tests due to KsftTerminate.=20 not ok 2 psp.data_send_bad_key # Totals: pass:1 fail:1 xfail:0 xpass:0 skip:0 error:0 # = = =20 # Responder logs (-15): =20 # STDERR: = =20 # Set PSP enable on device 3 to 0xf = =20 # DEBUG: ... = =20 # DEBUG: command: conn clr = =20 # DEBUG: ... = =20 # DEBUG: command: conn psp = =20 # WARN: old conn config still set! =20 # DEBUG: new data sock: psp =20 # DEBUG: create PSP connection =20 # DEBUG: ... = =20 # DEBUG: data sock closed = =20 # DEBUG: ... = = =20 # WARN: new data sock but no config = =20 # DEBUG: ... = =20 # DEBUG: data read 20 = =20 # DEBUG: ... =20 Traceback (most recent call last): =20 The problem is caused by the conn clr and conn psp RPC handlers running consecutively without the first connection being accepted and closed by the server. The fix is simply to match all conn clr commands with a data close RPC. The forces the trace to be: # Set PSP enable on device 3 to 0xf = =20 # DEBUG: ... = =20 # DEBUG: command: conn clr = =20 # DEBUG: ... # DEBUG: command: data close # DEBUG: new data sock: clear =20 # DEBUG: ... = =20 # DEBUG: command: conn psp # DEBUG: ... =20 # DEBUG: new data sock: psp =20 # DEBUG: create PSP connection So the closed connection from the conn clr is removed from the backlog before sending the ack for data close to the client. --- tools/testing/selftests/drivers/net/psp.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/drivers/net/psp.py b/tools/testing/sel= ftests/drivers/net/psp.py index 528a421ecf76..864d9fce1094 100755 --- a/tools/testing/selftests/drivers/net/psp.py +++ b/tools/testing/selftests/drivers/net/psp.py @@ -266,6 +266,7 @@ def assoc_sk_only_mismatch(cfg): the_exception =3D cm.exception ksft_eq(the_exception.nl_msg.extack['bad-attr'], ".dev-id") ksft_eq(the_exception.nl_msg.error, -errno.EINVAL) + _close_conn(cfg, s) =20 =20 def assoc_sk_only_mismatch_tx(cfg): @@ -283,6 +284,7 @@ def assoc_sk_only_mismatch_tx(cfg): the_exception =3D cm.exception ksft_eq(the_exception.nl_msg.extack['bad-attr'], ".dev-id") ksft_eq(the_exception.nl_msg.error, -errno.EINVAL) + _close_conn(cfg, s) =20 =20 def assoc_sk_only_unconn(cfg): --- base-commit: a8a6c8cc8796ac573fb3902803da28cfa374787c change-id: 20260126-psp-flaky-test-ea613ea5386c Best regards, --=20 Daniel Zahka