linux-kernel - Re: [PATCH net-next v5 2/4] net: devmem: refactor sock_devmem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQEMiuOlUutoi1iw@devvm11784.nha0.facebook.com>
Date: Tue, 28 Oct 2025 11:33:46 -0700
From: Bobby Eshleman <bobbyeshleman@...il.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Kuniyuki Iwashima <kuniyu@...gle.com>,
	Willem de Bruijn <willemb@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	David Ahern <dsahern@...nel.org>,
	Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Bobby Eshleman <bobbyeshleman@...a.com>
Subject: Re: [PATCH net-next v5 2/4] net: devmem: refactor
 sock_devmem_dontneed for autorelease split

On Mon, Oct 27, 2025 at 05:36:35PM -0700, Mina Almasry wrote:
> On Thu, Oct 23, 2025 at 2:00 PM Bobby Eshleman <bobbyeshleman@...il.com> wrote:
> >
> > From: Bobby Eshleman <bobbyeshleman@...a.com>
> >
> > Refactor sock_devmem_dontneed() in preparation for supporting both
> > autorelease and manual token release modes.
> >
> > Split the function into two parts:
> > - sock_devmem_dontneed(): handles input validation, token allocation,
> >   and copying from userspace
> > - sock_devmem_dontneed_autorelease(): performs the actual token release
> >   via xarray lookup and page pool put
> >
> > This separation allows a future commit to add a parallel
> > sock_devmem_dontneed_manual_release() function that uses a different
> > token tracking mechanism (per-niov reference counting) without
> > duplicating the input validation logic.
> >
> > The refactoring is purely mechanical with no functional change. Only
> > intended to minimize the noise in subsequent patches.
> >
> > Signed-off-by: Bobby Eshleman <bobbyeshleman@...a.com>
> > ---
> >  net/core/sock.c | 52 ++++++++++++++++++++++++++++++++--------------------
> >  1 file changed, 32 insertions(+), 20 deletions(-)
> >
> > diff --git a/net/core/sock.c b/net/core/sock.c
> > index a99132cc0965..e7b378753763 100644
> > --- a/net/core/sock.c
> > +++ b/net/core/sock.c
> > @@ -1082,30 +1082,13 @@ static int sock_reserve_memory(struct sock *sk, int bytes)
> >  #define MAX_DONTNEED_FRAGS 1024
> >
> >  static noinline_for_stack int
> > -sock_devmem_dontneed(struct sock *sk, sockptr_t optval, unsigned int optlen)
> > +sock_devmem_dontneed_autorelease(struct sock *sk, struct dmabuf_token *tokens,
> 
> Kind of a misnomer. This helper doesn't seem to autorelease, but
> really release the provided tokens, I guess. I would have
> sock_devmem_dontneed_tokens, but naming is hard :D
> 
> Either way, looks correct code move,
> 
> Reviewed-by: Mina Almasry <almasrymina@...gle.com>

Should we come up with a new name for "autorelease"? I was hoping to
find a name that could be consistent from the uAPI down into the token
handling code. Maybe "reap" is more clear than "release", since the real
difference is whether or not the kernel will reap leaked references on
close?

Maybe NETDEV_A_DMABUF_REAP_ON_CLOSE on the netlink side, and
sock_devmem_dontneed_tokens() and sock_devmem_dontneed_no_reap() here?

Best,
Bobby