Re: [PATCH net-next] net: devmem: add netdev_has_dmabuf_binding() helper

On 11.08.26 19:52, bobbyeshleman wrote:
> On Tue, Aug 11, 2026 at 12:44:07PM +0200, Dragos Tatulea wrote:
>>
>> On 11.08.26 09:24, Dragos Tatulea wrote:
>>>
>>>
>>> On 11.08.26 00:17, bobbyeshleman wrote:
>>>> On Mon, Aug 10, 2026 at 08:54:45PM +0300, Dragos Tatulea wrote:> [...]
>>>>> +bool netdev_has_dmabuf_binding(struct net_device *dev, struct device *dma_dev)
>>>>> +{
>>>>> +	struct net_devmem_dmabuf_binding *binding;
>>>>> +	unsigned long id;
>>>>> +	bool found = false;
>>>>> +
>>>>> +	rcu_read_lock();
>>>>> +	xa_for_each(&net_devmem_dmabuf_bindings, id, binding) {
>>>>> +		if (READ_ONCE(binding->dev) == dev &&
>>>>> +		    (!dma_dev || binding->attachment->dev == dma_dev)) {
>>>>> +			found = true;
>>>>> +			break;
>>>>> +		}
>>>>> +	}
>>>>> +	rcu_read_unlock();
>>>>> +
>>>>> +	return found;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(netdev_has_dmabuf_binding);
>>>>> +
>>>>>  void net_devmem_get_net_iov(struct net_iov *niov)
>>>>>  {
>>>>>  	net_devmem_dmabuf_binding_get(net_devmem_iov_binding(niov));
>>>>> -- 
>>>>> 2.54.0
>>>>>
>>>>
>>>> I think netdev_has_dmabuf_binding() can return false even when there
>>>> exists one or more in-flight skbs (e.g., in sk_write_queue) backed by
>>>> the txq binding (won't technically be inactive until the final reference
>>>> is dropped and the binding is freed)? If so, can this still detect when
>>>> it is safe to swap the underlying dma dev?
>>>>
>>> Oh, good point! I didn't realize that the binding is refcounted and can
>>> outlive its xarray slot.
>>>
>> I can only think of adding another list that tracks bindings for their
>> lifetime or between xarray erasure and deletion. Not too happy about it
>> though.
>>
>> There's also the possibility of iterating over dmabufs and their attachment.
>> But this requires a function in dmabuf to scan the dmabufs and attachments
>> under the internal lock similar to dma_buf_debug_show(). But I don't think
>> that will be accepted. So this is even worse.
>>
>> Thanks,
>> Dragos
> 
> I agree, those options aren't great.
> 
> Would it be possible to drop these skbs (based on some comparison with
> binding->attachment->dev) in validate_xmit_unreadable_skb()? Not sure if
> we have enough context at that point in the TX path?
> 
Even if we would, I wouldn't do it...

> tbh I'd lean towards your idea of adding a new lifetime list, if there
> isn't a better way.
>
Ok. Will implement the lifetime list (or xarray) if I can't come up with
something better until then.

Thanks,
Dragos