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

[Pavel Begunkov]

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