| Message ID | 20230401060509.3608259-1-dhavale@google.com |
|---|---|
| Headers | show |
| Series | USB: Fixes for handling ITER_UBUF | expand |
On 4/1/23 12:05?AM, Sandeep Dhavale wrote: > Since the commit 1e23db450cff ("io_uring: use iter_ubuf for single range > imports") .read_iter() can be called with iov type ITER_UBUF. > In such case dup_iter() will correctly dup but it will not allocate > any memory. But callers ffs_epfile_read_iter and ep_read_iter treat > this as a failure. > > Following patches address this by checking if iter_is_ubuf(). > Without the fix, async IOs from io_uring will be returned with -ENOMEM. Looks fine to me. The dup_iter() interface is somewhat unfortunate, as it doesn't return an error pointer. Hence NULL can be failed or success, depending on the type. Looks like cifs is the only other user of dup_iter(), and that checks the type first. You could do something like that too in the gadget code. Or we could fix the API... And it is kind of silly calling into dup_iter() when you don't need it. But for now, this will probably suffice: Acked-by: Jens Axboe <axboe@kernel.dk>
Since the commit 1e23db450cff ("io_uring: use iter_ubuf for single range imports") .read_iter() can be called with iov type ITER_UBUF. In such case dup_iter() will correctly dup but it will not allocate any memory. But callers ffs_epfile_read_iter and ep_read_iter treat this as a failure. Following patches address this by checking if iter_is_ubuf(). Without the fix, async IOs from io_uring will be returned with -ENOMEM. Sandeep Dhavale (2): usb: gadget: f_fs: Fix ffs_epfile_read_iter to handle ITER_UBUF usb: gadgetfs: Fix ep_read_iter to handle ITER_UBUF drivers/usb/gadget/function/f_fs.c | 2 +- drivers/usb/gadget/legacy/inode.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)