From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E231B29CEB; Thu, 5 Feb 2026 01:34:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770255245; cv=none; b=QEbI7Vx4P8h5cpr4YszihzQfDQaJf63iKYS/mWfdnyBSgr93GP7PR6Gig7Hh+/47liG/FfOXBM8KkoEcFvrftVBXzdpSfdfmmQnSLJidoswyJ00BzRkVCNAcWdQBF5+NhWbwLJSI74q/lMblRNhwAc2qVOUEq4KWmGY4Y1Dwnls= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770255245; c=relaxed/simple; bh=0u0PVRNuSSgJ24J9RSkTtvGB/Sq3SToazqRzHf3k9oM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OVLlK5VM1vo41kmjKgEfgtkNovH3+1iaFlIElx4iZ2LPjOIoLB2+zbUbag+Uij2SCKwm8TgEIzNEEgtm0E5gDLrD4e4neNlrd7XjhUq0/cCYsXpNsWq5RDed6BSC875M3llo8hJ6MAD8dzWdVeq32AIXlyhoAiuv86oIBOLTDPM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JvLrpYKJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JvLrpYKJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE722C4CEF7; Thu, 5 Feb 2026 01:34:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770255244; bh=0u0PVRNuSSgJ24J9RSkTtvGB/Sq3SToazqRzHf3k9oM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JvLrpYKJ+A2rWVs3m/oJxbPk0NKGBV3yMRqt1DguRhcao+2cLLgtrW+isjepeRdRm 0KBV76gfQqSSxGOhOmvMM/RyLPDWlG9S1kHtvuZWyk6AXt/sEstH8IIJifkP/p6xIB BD1m4M+QGdw13h/YVfZwgxp2lTPt0aVOYTVn7ABLW4DNV9iMQ9A41ZZALHaJZNkFBx RThyPw3UfVlM+waX3tvsKyhHDU7VmBVhtNfnW38PH68F25bDbuyv+t/Y1Wb2aUrgSb SAdRL3rU2JebD0trLF5grO4sIulV/wTIwizO/fIbDW6lGkCaEIYz+l8uUs1BvfX/pc Qqeo72b6g/UsA== Date: Wed, 4 Feb 2026 17:34:01 -0800 From: Jakub Kicinski To: Vladimir Oltean Cc: Larysa Zaremba , bpf@vger.kernel.org, Claudiu Manoil , Wei Fang , Clark Wang , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Tony Nguyen , Przemek Kitszel , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Simon Horman , Shuah Khan , Alexander Lobakin , Maciej Fijalkowski , "Bastien Curutchet (eBPF Foundation)" , Tushar Vyavahare , Jason Xing , "Ricardo B. =?UTF-8?B?TWFybGniiJrCrnJl?=" , Eelco Chaudron , Lorenzo Bianconi , Toke Hoiland-Jorgensen , imx@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org, Aleksandr Loktionov Subject: Re: [PATCH bpf 6/6] net: enetc: use truesize as XDP RxQ info frag_size Message-ID: <20260204173401.282899d0@kernel.org> In-Reply-To: <20260205005901.gnju3zmqimtgeu2b@skbuf> References: <20260203105417.2302672-1-larysa.zaremba@intel.com> <20260203105417.2302672-7-larysa.zaremba@intel.com> <20260205005901.gnju3zmqimtgeu2b@skbuf> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 5 Feb 2026 02:59:01 +0200 Vladimir Oltean wrote: > Thanks! This is an extremely subtle corner case. I appreciate the patch > and explanation. > > I did run tests on the blamed commit (which I still have), but to catch > a real issue in a meaningful way it would have been required to have a > program which calls bpf_xdp_adjust_tail() with a very large offset. > I'm noting that I'm seeing the WARN_ON() much easier after your fix, but > before, it was mostly inconsequential for practical cases. > > Namely, the ENETC truesize is 2048, and XDP_PACKET_HEADROOM is 256. > First buffers also contain the skb_shared_info (320 bytes), while > subsequent buffers don't. I can't wrap my head around this series, hope you can tell me where I'm going wrong. AFAICT enetc splits the page into two halves for small MTU. So we have | 2k | 2k | ----------------------------- ----------------------------- | hroom | data | troom/shinfo | hroom | data | troom/shinfo | ----------------------------- ----------------------------- If we attach the second chunk as frag well have: offset = 2k + hroom size = data.len But we use truesize / frag_size = 2k so tailroom = rxq->frag_size - skb_frag_size(frag) - skb_frag_off(frag); tailroom = 2k - data.len - 2k tailroom = -data.len WARN(tailroom < 0) -> yes The frag_size thing is unusable for any driver that doesn't hand out full pages to frags?