Re: [PATCH v7 05/13] block: add dma-buf support for raw bdev

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] block: blkdev_write_iter swallows -EBUSY and returns 0 for dmabuf direct writes
--

commit afbe81886595b7f9b2e6456a34c387448997c06f
Author: Pavel Begunkov <asml.silence@gmail.com>

block: add dma-buf support for raw bdev

Add a simple proxy implementation of init_dma_buf_io_ctx() forwarding
the call to a new struct block_device_operations operation. Also reject
dma-buf backed iterators for buffered IO.

> diff --git a/block/fops.c b/block/fops.c
> index 40a8ceeec1940..0e5536f05899d 100644
> --- a/block/fops.c
> +++ b/block/fops.c
> @@ -788,7 +788,8 @@ static ssize_t blkdev_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  
>  	if (iocb->ki_flags & IOCB_DIRECT) {
>  		ret = blkdev_direct_write(iocb, from);
> -		if (ret >= 0 && iov_iter_count(from)) {
> +		if (ret >= 0 && iov_iter_count(from) &&
> +		    !iov_iter_is_dmabuf_map(from)) {

[Severity: Medium]
Could skipping this fallback result in returning a false 0 to userspace
instead of an error code?

If a dmabuf direct write is submitted via io_uring to a block device region
where page cache invalidation fails (e.g., due to an elevated refcount from
mmap), blkdev_direct_write() intentionally translates -EBUSY to a 0 return
value to trigger a fallback to buffered I/O:

block/fops.c:blkdev_direct_write() {
	...
	written = kiocb_invalidate_pages(iocb, count);
	if (written) {
		if (written == -EBUSY)
			return 0;
		return written;
	}
	...
}

Since the !iov_iter_is_dmabuf_map(from) check skips the
direct_write_fallback() path, ret remains 0. Would this cause userspace to
incorrectly receive 0 (indicating EOF or no bytes written) instead of an
error code like -EOPNOTSUPP or -EBUSY? Applications that retry on 0-byte
writes might enter an infinite retry loop.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790602223.git.asml.silence@gmail.com?part=5