Re: [PATCH v6 01/13] dma-buf: introduce initial file I/O infrastructure

[Matthew Brost <matthew.brost@intel.com>]

On Tue, Sep 22, 2026 at 10:08:38AM +0100, Pavel Begunkov wrote:
> On 9/21/26 14:53, sashiko-bot@kernel.org wrote:
> ...>>   }
> > [ ... ]
> > > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map,
> > > +			struct sg_table *sgt)
> > > +{
> > > +	unsigned seg_shift = ~0U;
> > > +	struct scatterlist *sg;
> > > +	unsigned long tmp;
> > > +	int ret;
> > > +
> > > +	for_each_sgtable_dma_sg(sgt, sg, tmp)
> > > +		seg_shift = min(seg_shift, __ffs(sg_dma_len(sg)));
> > > +
> > > +	ret = percpu_ref_init(&map->refs, dma_buf_io_map_refs_release, 0,
> > > +			      GFP_KERNEL);
> > 
> > [Severity: High]
> > Does this GFP_KERNEL allocation violate DMA-buf locking rules?
> > 
> > dma_buf_io_create_map() calls ctx->dev_ops->map(ctx) while holding the
> > dmabuf->resv ww_mutex. If the driver then calls dma_buf_io_init_map() under
> > this lock, the GFP_KERNEL allocation could deadlock if memory reclaim
> > attempts to acquire dma_resv locks.
> 
> Most of these look trivial, going to fix them. This one, however,
> doesn't sound true AFAIU, I haven't heard about any blank ban on
> GFP_KERNEL allocation under resv lock.
> 

I can confirm this definitely not correct - see dma_resv_lockdep it
acquires dma_resv then fs_reclaim_acquire(GFP_KERNEL). Shrinker enter
direct reclaim and try to take dma-resv locks, but not block on the
lock.

Matt

> -- 
> Pavel Begunkov
>