Re: [PATCH net-next v5 2/4] net: devmem: refactor sock_devmem_dontneed for autorelease split

[Bobby Eshleman <bobbyeshleman@gmail.com>]

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@gmail.com> wrote:
> >
> > From: Bobby Eshleman <bobbyeshleman@meta.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@meta.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@google.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