On 9/30/26 04:00, Matthew Brost wrote:
On Mon, Sep 21, 2026 at 02:38:45PM +0100, Pavel Begunkov wrote:
...>> +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx)
+{ + struct dma_buf *dmabuf = ctx->dmabuf; + struct dma_buf_io_map *map; + long ret; + + guard(mutex)(&ctx->map_create_mutex); + + scoped_guard(mutex, &ctx->map_mutex) { + if (ctx->maps_killed) + return ERR_PTR(-ENOENT); + /* recheck under the lock in case it has already been re-created */ + map = __dma_buf_io_get_map(ctx); + if (map) + return map; + } + + dma_buf_io_wait_active_maps(ctx); + + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); + if (ret) + return ERR_PTR(ret); + + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, + true, MAX_SCHEDULE_TIMEOUT); + if (ret <= 0) { + if (!ret) + ret = -EAGAIN; + dma_resv_unlock(dmabuf->resv); + return ERR_PTR(ret); + } + + map = ctx->dev_ops->map(ctx);I'm playing around this code now. I think you need the dma_resv_wait_timeout after the 'map'? If a device doesn't support p2p ->map() will typically trigger an async migrate to system memory and data will be moving but the map is valid - Xe 100% does this, I checked AMDGPU and fairly confident it has the same async behavior.
There is a wait right before because I read somewhere in dma-buf comments that I need to do that, sounds a bit odd if I need to wait on fences before and after. I can add it, just curious how come that other dma_buf_map_attachment() callers don't need to do that. Or maybe they wait somewhere else? -- Pavel Begunkov
