On Tue, Sep 22, 2026 at 10:08:38AM +0100, Pavel Begunkov wrote: > On 9/21/26 14:53, [email protected] 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 >
