On Wed, Jan 21, 2026 at 6:50 PM Jakub Kicinski <[email protected]> wrote: > > On Wed, 21 Jan 2026 18:37:56 -0800 Bobby Eshleman wrote: > > > > Show an example of the three steps: returning the tokens, unbinding, > > > > and closing the > > > > sockets (TCP/NL)? > > > > > > TBH I read the doc before reading the code, which I guess may actually > > > be better since we don't expect users to read the code first either.. > > > > > > Now after reading the code I'm not sure the doc explains things > > > properly. AFAIU there's no association of token <> socket within the > > > same binding. User can close socket A and return the tokens via socket > > > B. As written the doc made me think that there will be a leak if socket > > > is closed without releasing tokens, or that there may be a race with > > > data queued but not read. Neither is true, really? > > > > 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?
