On Mon, Nov 6, 2023 at 3:44 PM David Ahern <dsahern@xxxxxxxxxx> wrote: > > On 11/5/23 7:44 PM, Mina Almasry wrote: > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > > index eeeda849115c..1c351c138a5b 100644 > > --- a/include/linux/netdevice.h > > +++ b/include/linux/netdevice.h > > @@ -843,6 +843,9 @@ struct netdev_dmabuf_binding { > > }; > > > > #ifdef CONFIG_DMA_SHARED_BUFFER > > +struct page_pool_iov * > > +netdev_alloc_devmem(struct netdev_dmabuf_binding *binding); > > +void netdev_free_devmem(struct page_pool_iov *ppiov); > > netdev_{alloc,free}_dmabuf? > Can do. > I say that because a dmabuf can be host memory, at least I am not aware > of a restriction that a dmabuf is device memory. > In my limited experience dma-buf is generally device memory, and that's really its use case. CONFIG_UDMABUF is a driver that mocks dma-buf with a memfd which I think is used for testing. But I can do the rename, it's more clear anyway, I think. On Mon, Nov 6, 2023 at 11:45 PM Yunsheng Lin <linyunsheng@xxxxxxxxxx> wrote: > > On 2023/11/6 10:44, Mina Almasry wrote: > > + > > +void netdev_free_devmem(struct page_pool_iov *ppiov) > > +{ > > + struct netdev_dmabuf_binding *binding = page_pool_iov_binding(ppiov); > > + > > + refcount_set(&ppiov->refcount, 1); > > + > > + if (gen_pool_has_addr(binding->chunk_pool, > > + page_pool_iov_dma_addr(ppiov), PAGE_SIZE)) > > When gen_pool_has_addr() returns false, does it mean something has gone > really wrong here? > Yes, good eye. gen_pool_has_addr() should never return false, but then again, gen_pool_free() BUG_ON()s if it doesn't find the address, which is an extremely severe reaction to what can be a minor bug in the accounting. I prefer to leak rather than crash the machine. It's a bit of defensive programming that is normally frowned upon, but I feel like in this case it's maybe warranted due to the very severe reaction (BUG_ON). -- Thanks, Mina