Re: [PATCH net-next v22 04/13] netdev: netdevice devmem allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 28 Aug 2024 00:20:23 -0700 Mina Almasry wrote:
> > On Sun, 25 Aug 2024 04:15:02 +0000 Mina Almasry wrote:  
> > > +void net_devmem_free_dmabuf(struct net_iov *niov)
> > > +{
> > > +     struct net_devmem_dmabuf_binding *binding = net_iov_binding(niov);
> > > +     unsigned long dma_addr = net_devmem_get_dma_addr(niov);
> > > +
> > > +     if (gen_pool_has_addr(binding->chunk_pool, dma_addr, PAGE_SIZE))
> > > +             gen_pool_free(binding->chunk_pool, dma_addr, PAGE_SIZE);  
> >
> > Is the check necessary for correctness? Should it perhaps be a WARN
> > under DEBUG_NET instead? The rest LGTM:
> >  
> 
> Not really necessary for correctness per se, but if we try to free a
> dma_addr that is not in a gen_pool (due to some other bug in the
> code), then gen_pool_free ends up BUG_ON, crashing the kernel.
> 
> Arguably gen_pool_free should not BUG_ON, but I think that's an old
> API, and existing call sites have worked around the BUG_ON by doing a
> gen_pool_has_addr check like I do here, for example kernel/dma/pool.c.
> So I did not seek to change this established behavior.
> 
> I think WARN seems fine to me, but maybe not under DEBUG_NET. I don't
> want production code crashing due to this error, if it's OK with you.
> 
> Unless I hear otherwise I'll add a WARN without debug here.

WARN makes sense, I didn't know about the BUG_ON() hiding inside
gen_pool :(




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux