On 2/25/25 10:41 AM, Mina Almasry wrote: > On Tue, Feb 25, 2025 at 5:04 AM Paolo Abeni <pabeni@xxxxxxxxxx> wrote: >> >> On 2/22/25 8:15 PM, Mina Almasry wrote: >> [...] >>> @@ -119,6 +122,13 @@ void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding) >>> unsigned long xa_idx; >>> unsigned int rxq_idx; >>> >>> + xa_erase(&net_devmem_dmabuf_bindings, binding->id); >>> + >>> + /* Ensure no tx net_devmem_lookup_dmabuf() are in flight after the >>> + * erase. >>> + */ >>> + synchronize_net(); >> >> Is the above statement always true? can the dmabuf being stuck in some >> qdisc? or even some local socket due to redirect? >> > > Yes, we could have have netmems in the TX path in the qdisc or waiting > for retransmits that still have references to the dmabuf, and that's > fine here I think. skbs with references to netmem from a dmabuf can get stuck in retransmit queues for a long time. The comment should at least acknowledge that.
