mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Sandeep Dhavale <dhavale@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Keith Busch <kbusch@kernel.org>
Cc: kernel-team@android.com, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/2] USB: Fixes for handling ITER_UBUF
Date: Sat, 1 Apr 2023 10:08:54 -0600	[thread overview]
Message-ID: <1a55abad-bf4c-606a-2217-22447bfd343b@kernel.dk> (raw)
In-Reply-To: <20230401060509.3608259-1-dhavale@google.com>

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>

-- 
Jens Axboe


      parent reply	other threads:[~2023-04-01 16:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-01  6:05 Sandeep Dhavale
2023-04-01  6:05 ` [PATCH v1 1/2] usb: gadget: f_fs: Fix ffs_epfile_read_iter to handle ITER_UBUF Sandeep Dhavale
2023-04-01  6:05 ` [PATCH v1 2/2] usb: gadgetfs: Fix ep_read_iter " Sandeep Dhavale
2023-04-01 16:08 ` Jens Axboe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a55abad-bf4c-606a-2217-22447bfd343b@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=dhavale@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kbusch@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®