From nobody Sun Feb 8 18:09:11 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0605B3C1994; Tue, 3 Feb 2026 16:18:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770135512; cv=none; b=k61D+0i6aYxWJY3xhA5luX9+cP31TNN8P78I3jK8mvVCwsMX1lJ844hevJk955Nwy6i/bTp7+Q3sFNoL00XNHEq1VvBRA8RI2DaACg6Ju0nJQ6onrIrBX918ZgyQZ2+xQ4pIN7eA3tdd6kKS/1hxRkrioADn3pHyXOnZJwwrwqQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770135512; c=relaxed/simple; bh=SUncJcboFs8uhYhoRkacGOoojC61QIaNsbPXLEKkv7A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=O1qYEsfqSL4M+z11qyqe/0XmfhGpiu12s7KwPk5w3E9c7CJ5sQkU4G1oAe3q7qsV064+8MARXrF9wPFbO5nl5LlsPZgE4sJMifFpn7B7b/mRWYFDh45DZ57zQ0w5HZFXBBekCRJLjx4uRVbz8q4lYaWKnj810pD9PsAqMS/f/zc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=SJL0JF77; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="SJL0JF77" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1770135510; x=1801671510; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SUncJcboFs8uhYhoRkacGOoojC61QIaNsbPXLEKkv7A=; b=SJL0JF77wLRzrRKqPxD6deiyIdFu5yzWDvVEXdJ4NccBbLlAnBI+bAA8 DsDMj1ScRV/gfX5M1Zq6Z5n8BvTclYvlMlDgwvKEDXFpC/PRg3ixd0Njf VoM7TLar43tA0CHwWA5i2vdLJfEg9wv6gJWmYk8z1Vi/qg2JnOx/Tqsbg 8eip4MKwoTWHE8q4TMwVmhozxARKVdfE9QJJEPHn5tGLups9x7vOwKbR2 DNI6GRGM8AG1H15oioacIxwhjuziqpvHVSDKeazu2zlWQQKoYumXe/rCK MU5udcsXROgMvBw8HKf6dKX9eHxtXW7IEXRocazVoaT+bI50hdVkhNvXO w==; X-CSE-ConnectionGUID: jdtF7mdqR/+2GFgTYcIh6A== X-CSE-MsgGUID: 1s7mlTnhQuuHXH+nhrmQbQ== X-IronPort-AV: E=McAfee;i="6800,10657,11690"; a="71391886" X-IronPort-AV: E=Sophos;i="6.21,270,1763452800"; d="scan'208";a="71391886" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2026 08:18:30 -0800 X-CSE-ConnectionGUID: 24Zjgv7WS4KIiFq7lGuk5A== X-CSE-MsgGUID: XdSw/hC8SxmRy7p7ZS2e4A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,270,1763452800"; d="scan'208";a="214645524" Received: from irvmail002.ir.intel.com ([10.43.11.120]) by fmviesa004.fm.intel.com with ESMTP; 03 Feb 2026 08:18:25 -0800 Received: from lincoln.igk.intel.com (lincoln.igk.intel.com [10.102.21.235]) by irvmail002.ir.intel.com (Postfix) with ESMTP id 2DC302FC76; Tue, 3 Feb 2026 16:18:23 +0000 (GMT) From: Larysa Zaremba To: bpf@vger.kernel.org Cc: Andrii Nakryiko , Eduard Zingerman , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Maciej Fijalkowski , "Bastien Curutchet (eBPF Foundation)" , Aleksandr Loktionov , Larysa Zaremba , Tushar Vyavahare , =?UTF-8?q?Ricardo=20B=2E=20Marli=C3=A8re?= , Jason Xing , Magnus Karlsson , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Alexander Lobakin Subject: [PATCH bpf 1/2] selftests/xsk: properly handle batch ending in the middle of a packet Date: Tue, 3 Feb 2026 16:50:57 +0100 Message-ID: <20260203155103.2305816-2-larysa.zaremba@intel.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260203155103.2305816-1-larysa.zaremba@intel.com> References: <20260203155103.2305816-1-larysa.zaremba@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Referenced commit reduced the scope of the variable pkt, so now it has to be reinitialized via pkt_stream_get_next_rx_pkt(), which also increments some counters. When the packet is interrupted by the batch ending, pkt stream therefore proceeds to the next packet, while xsk ring still contains the previous one, this results in a pkt_nb mismatch. Decrement the affected counters when packet is interrupted. Fixes: 8913e653e9b8 ("selftests/xsk: Iterate over all the sockets in the re= ceive pkts function") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba --- tools/testing/selftests/bpf/prog_tests/test_xsk.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/test= ing/selftests/bpf/prog_tests/test_xsk.c index 5af28f359cfd..69a5a9a5189b 100644 --- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c +++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c @@ -1090,6 +1090,8 @@ static int __receive_pkts(struct test_spec *test, str= uct xsk_socket_info *xsk) xsk_ring_prod__cancel(&umem->fq, nb_frags); } frags_processed -=3D nb_frags; + pkt_stream_cancel(pkt_stream); + pkts_sent--; } =20 if (ifobj->use_fill_ring) --=20 2.52.0 From nobody Sun Feb 8 18:09:11 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76CD93C1960; Tue, 3 Feb 2026 16:18:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770135514; cv=none; b=lVDBQVA6NFur27Ifhf4lsOlizpysqIUfze9aLESgeC5eNNQewn5CTCTsa++iJHhbSMZ+ez5QUlB/ZLyIZAUt2/3ej3phA8HI050MYCdPTCnTOK8G96zbyzNsalMo1eRpsFWvlloPbgMKDCcp0TzSqRcJWdVl+pLoPPgYBjYSkCk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770135514; c=relaxed/simple; bh=vKe54uOjeoLP4XUWoAXwXrz1MoBrvz+ZvQqj8AMaXpE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CwlZDb2vBzS8Ddnbs+BaWR1sPJdBHZzA9f0wyAmCeYqEjTRl5tbZffw08kdtYeoJdI0eLbk0j2xcZaK+lWDaHQNKGPAOs8Bzld1r/76WWLkJzbuaQNtNXVUFETfTR9fyT7yDLahHziOGlxrLaTtPxldtGsA8ojL3IMApwafaCKI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EWw80xKn; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EWw80xKn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1770135512; x=1801671512; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vKe54uOjeoLP4XUWoAXwXrz1MoBrvz+ZvQqj8AMaXpE=; b=EWw80xKnX0TUtd6t0aPGSLd9VuuwwtEsv8arkq1ZocDbJoCVG4m/vhwc Q7WMY1YMCI3VOkiLGVRGUmakKx9o5rrr7ZaMGVIDoTf/cdlzW4jCVCeSz Il5FSfRSPrXI8ru/GlOORlZ/62AV5H9kch6B2zur4Q0IDZ3Bqb6Qws96E Pmp1JcNDlG3Fxh18W1sLU6lc4ST24v8iJleqiVOSliJIDgjvSDzcWq1qH Pz6YgxXmR4ZjUgS7+pC9WNYq3/aq97tSjUoD8J6Y9gSilPZ1RG9/3bDt1 iKuXORcYHGEcO7DVh2GEFycRdavsNm4hu55SJebrRVcC7Gs5vuNuy2bQK Q==; X-CSE-ConnectionGUID: D0qR8wLBRfKbZScxszaGcA== X-CSE-MsgGUID: SiSA/DOZTw67quUx9tRIdQ== X-IronPort-AV: E=McAfee;i="6800,10657,11690"; a="71391903" X-IronPort-AV: E=Sophos;i="6.21,270,1763452800"; d="scan'208";a="71391903" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2026 08:18:31 -0800 X-CSE-ConnectionGUID: sf8Wi3rnTri+jVQmBVB+kg== X-CSE-MsgGUID: RWIRTRIoQwKUffMAXKgNuw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,270,1763452800"; d="scan'208";a="214645538" Received: from irvmail002.ir.intel.com ([10.43.11.120]) by fmviesa004.fm.intel.com with ESMTP; 03 Feb 2026 08:18:27 -0800 Received: from lincoln.igk.intel.com (lincoln.igk.intel.com [10.102.21.235]) by irvmail002.ir.intel.com (Postfix) with ESMTP id 0AD552FC77; Tue, 3 Feb 2026 16:18:24 +0000 (GMT) From: Larysa Zaremba To: bpf@vger.kernel.org Cc: Andrii Nakryiko , Eduard Zingerman , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Maciej Fijalkowski , "Bastien Curutchet (eBPF Foundation)" , Aleksandr Loktionov , Larysa Zaremba , Tushar Vyavahare , =?UTF-8?q?Ricardo=20B=2E=20Marli=C3=A8re?= , Jason Xing , Magnus Karlsson , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Alexander Lobakin Subject: [PATCH bpf 2/2] selftests/xsk: fix number of Tx frags in invalid packet Date: Tue, 3 Feb 2026 16:50:58 +0100 Message-ID: <20260203155103.2305816-3-larysa.zaremba@intel.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260203155103.2305816-1-larysa.zaremba@intel.com> References: <20260203155103.2305816-1-larysa.zaremba@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The issue occurs in TOO_MANY_FRAGS test case when xdp_zc_max_segs is set to an odd number. TOO_MANY_FRAGS test case contains an invalid packet consisting of (xdp_zc_max_segs) frags. Every frag, even the last one has XDP_PKT_CONTD flag set. This packet is expected to be dropped. After that, there is a valid linear packet, which is expected to be received back. Once (xdp_zc_max_segs) is an odd number, the last packet cannot be received, if packet forwarding between Rx and Tx interfaces relies on the ethernet header, e.g. checks for ETH_P_LOOPBACK. Packet is malformed, if all traffic is looped. Turns out, sending function processes multiple invalid frags as if they were in 2-frag packets. So once the invalid mbuf packet contains an odd number of those, the valid packet after gets paired with the previous invalid descriptor, and hence does not get an ethernet header generated, so it is either dropped or malformed. Make invalid packets in verbatim mode always have only a single frag. For such packets, number of frags is otherwise meaningless, as descriptor flags are pre-configured in verbatim mode and packet data is not generated for invalid descriptors. Fixes: 697604492b64 ("selftests/xsk: add invalid descriptor test for multi-= buffer") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba --- tools/testing/selftests/bpf/prog_tests/test_xsk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/test= ing/selftests/bpf/prog_tests/test_xsk.c index 69a5a9a5189b..bab4a31621c7 100644 --- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c +++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c @@ -433,7 +433,7 @@ static u32 pkt_nb_frags(u32 frame_size, struct pkt_stre= am *pkt_stream, struct pk } =20 /* Search for the end of the packet in verbatim mode */ - if (!pkt_continues(pkt->options)) + if (!pkt_continues(pkt->options) || !pkt->valid) return nb_frags; =20 next_frag =3D pkt_stream->current_pkt_nb; --=20 2.52.0