From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794560926; b=Fqfi0D1UlPDv9IH6sJevUMSrLt0sYtwYJyljnOhK4pKEhZDnrXWeX/CiU5YjBo6YUi1U HWfFG4kUC4co5XGS0o1HtifrE1ZXGEjRXxHHUNbtse+zgwaw7RCblZvFzryVZ9i5jFWEV AWvcAdSl19URFdLN/wmv5DEz28zfO39iHVlwvMqEkxJLyFYJqjPs5Iv/MyMdjR+mSi5C7 /Ot+pMSFhqQEieYlEhQ1yYLUlKLHWp5vadyUXbYrYBAI9jx618r73S9Y+aQLv1MA7h+jm OCzuTndIocVS6bQsHxvsCy9Qrpnl+ZvjW/k/S8eae+P7i/hcCDWcEn6amYF4YQPv60Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794560926; h=Received:DKIM-Signature:From:To:Cc:Subject:In-Reply-To:References: Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=M3J02I9fhxLNnztawYzUAlQ6QhBDBuVfwK+zFsDggxI=; b=5Oek/wlbB0pqSdvC9//R2TF9iMKVo9EzoPn2/tUkO3FE4AMKhSy7sRe+4IIpXDDUTER1 t4IYyDKNKYmCRLQOwvC17LuWAAk39TNUUN9c4Y5Yy54PJzzlw436mMDAdenPky6Hs9K2D Wi+Qyez429xdjWPhjWsLqv0sGK1+u80Tm8Gc3roe+3rlahVB7GQSqXjq1KpaJHizy2MOb KgRH3MCYpHizglEmom4PEgi9wWJ97vSfg1zv/0/0LP/9jW+qVCJRTjmIRbmobyKn8uMeQ KxMSt3MANH69geYD9K4vhhBkNvWdeuo5fIgdSoi6qkwImvjbnfX9PVUGfNv6cTZMn2Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=KD5ni9Rf; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC2C3606A321; Fri, 13 Nov 2026 09:08:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=KD5ni9Rf Received: by smtp.kernel.org (Postfix) with ESMTPSA id A80211F000C4; Fri, 13 Nov 2026 09:08:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794560926; bh=M3J02I9fhxLNnztawYzUAlQ6QhBDBuVfwK+zFsDggxI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=KD5ni9RfgR2oPiPnTxi9WLqFkN9jV0P/xl5AkArK9PZNzck6d6GSiqqcJLJ/1h143 kjxcOQqn84Lfh85aDV87hexctxhF/nU0KHAKhGlqODU9EPG3GpscaiR8/OGM17Y3eE 3JsA1PZQHTpuU+g/NR8TRSaE1KtmYUXa6QZ5/LRs9MNCOW4VEWTtlj41F3Emlca/ji QSTeQmwaIArDJNMwK5hgHd+szqeNvFaSZBmzERMWwJ0Ep/wRiO886k/Dii+Yrm78am jBbocMXOzmMr6FOUxxx9DdhnxLTzPGk3dhKjrv6HkbPkj7JDAR71qYfKrQSJOWyDMk gK4o4Jm5Ej1KQ== From: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= To: Mina Almasry Cc: Magnus Karlsson , Maciej Fijalkowski , Stanislav Fomichev , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , Randy Dunlap , Alexander Duyck , kernel-team@meta.com, Andrew Lunn , Jesper Dangaard Brouer , Ilias Apalodimas , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Pavel Begunkov , Jens Axboe , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , netdev@vger.kernel.org, bpf@vger.kernel.org, io-uring@vger.kernel.org, "Mike Marciniszyn (Meta)" , Weiming Shi , Nikolay Aleksandrov , David Wei , Alexander Lobakin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Stuart Clark Subject: Re: [PATCH net-next v1 01/11] net: Get skb fragment addresses through netmem In-Reply-To: References: <20261110102039.1002605-1-bjorn@kernel.org> <20261110102039.1002605-2-bjorn@kernel.org> Date: Fri, 13 Nov 2026 10:08:42 +0100 Message-ID: <87pkw9p085.fsf@all.your.base.are.belong.to.us> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mina Almasry writes: > On Tue, Nov 10, 2026 at 2:21=E2=80=AFAM Bj=C3=B6rn T=C3=B6pel wrote: >> >> skb_frag_address() goes through struct page, so a net_iov never has an >> address. Only unreadable memory should lack one: XDP and BPF read >> fragments through this helper, and AF_XDP UMEM will back readable >> net_iovs. netmem_address() also returns NULL, not a bogus pointer, for >> an unmapped highmem page. >> >> Generic code needs the size of a net_iov to find its address, so keep >> it in struct net_iov_area instead of the devmem binding. >> >> Suggested-by: Mina Almasry >> Suggested-by: Stanislav Fomichev >> Signed-off-by: Bj=C3=B6rn T=C3=B6pel > > Are the changes for niov_shift some kind of rebase error? I don't see > how they're related. Otherwise changes LGTM. Not a rebase error, but it's early. Nothing here reads it. The generic code that needs it is net_iov_address() in patch 4; in this patch netmem_address() still returns NULL for every net_iov. I'll move it to patch 4. Bj=C3=B6rn