On 9/30/26 07:54, Matthew Brost wrote:
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.
Just to double check, I believe by "this" you mean that the
sashiko report is incorrect. I'm going to leave it as is, but
let me know if I'm wrong.
--
Pavel Begunkov
