netdev - Re: [PATCH net-next v10 4/5] net: devmem: document NETDEV_A_DMABUF

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260121194615.33dc0812@kernel.org>
Date: Wed, 21 Jan 2026 19:46:15 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Bobby Eshleman <bobbyeshleman@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, 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>, Mina Almasry <almasrymina@...gle.com>, Arnd Bergmann
 <arnd@...db.de>, Jonathan Corbet <corbet@....net>, Andrew Lunn
 <andrew+netdev@...n.ch>, Shuah Khan <shuah@...nel.org>, Donald Hunter
 <donald.hunter@...il.com>, Stanislav Fomichev <sdf@...ichev.me>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kselftest@...r.kernel.org, asml.silence@...il.com,
 matttbe@...nel.org, skhawaja@...gle.com, Bobby Eshleman
 <bobbyeshleman@...a.com>
Subject: Re: [PATCH net-next v10 4/5] net: devmem: document
 NETDEV_A_DMABUF_AUTORELEASE netlink attribute

On Wed, 21 Jan 2026 19:25:27 -0800 Bobby Eshleman wrote:
> > > That is correct, neither is true. If the two sockets share a binding the
> > > kernel doesn't care which socket received the token or which one
> > > returned it. No token <> socket association. There is no
> > > queued-but-not-read race either. If any tokens are not returned, as long
> > > as all of the binding references are eventually released and all sockets
> > > that used the binding are closed, then all references will be accounted
> > > for and everything cleaned up.  
> >
> > Naming is hard, but I wonder whether the whole feature wouldn't be
> > better referred to as something to do with global token accounting
> > / management? AUTORELEASE makes sense but seems like focusing on one
> > particular side effect.  
> 
> Good point. The only real use case for autorelease=on is for backwards
> compatibility... so I thought maybe DEVMEM_A_DMABUF_COMPAT_TOKEN
> or DEVMEM_A_DMABUF_COMPAT_DONTNEED would be clearer?

Hm. Maybe let's return to naming once we have consensus on the uAPI.

Does everyone think that pushing this via TCP socket opts still makes
sense, even tho in practice the TCP socket is just how we find the
binding?