25 Feb
2025
25 Feb
'25
6:03 p.m.
On 2/25/25 10:41 AM, Mina Almasry wrote:
On Tue, Feb 25, 2025 at 5:04 AM Paolo Abeni pabeni@redhat.com 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.