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 <[email protected]> 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/[email protected]?part=5
