From: John Keeping <john@metanate.com>
To: Shang Shi <shangshi@google.com>
Cc: linux-usb@vger.kernel.org,
Gabriel Beddingfield <beddingfield@google.com>
Subject: Re: USB: f_fs: Use Functionfs with kernel AIO
Date: Thu, 2 Dec 2021 14:46:08 +0000 [thread overview]
Message-ID: <YajcMBF7K1IaCkVe@donbot> (raw)
In-Reply-To: <CAJkDvNk4G3WJuitZa+oPuNhkrCPNiwwG-zyNET+urWVWAda+cw@mail.gmail.com>
On Wed, Dec 01, 2021 at 09:04:27AM -0800, Shang Shi wrote:
> This is Shang Shi from Google. As we are examining the Andorid adb
> daemon implementation in AOSP, we found that there's a concern on
> functionfs that an io_submit syscall on IN/OUT endpoint after endpoint
> becomes disabled could end up blocking [1]. AOSP kills a thread to
> avoid it blocking on io_submit, which is not an elegant way to exist.
>
> Is it true that io_submit syscall could end up blocking after endpoint
> is disabled? Would opening endpoint file with O_NONBLOCK resolve the
> issue?
Looking at ffs_epfile_io() it seems that it can block if the endpoint is
disabled, and indeed there may be a race there between the disabled
notification and the next submit arriving.
There was a recent proposed patch [1] which looks like it inadvertently
addresses this race, but there are other issues with that patch so it's
not a fix for this.
From the code, indeed O_NONBLOCK does avoid any risk of blocking, but it
means you can't queue up I/O requests before the gadget is activated,
although maybe that's not a problem in practice.
[1] https://lore.kernel.org/linux-usb/20211201100205.25448-1-quic_wcheng@quicinc.com/
> From the ffs-aio-example "aio_simple.c", it seems that as long as we
> read and process control events before any read/write (with
> io_submit), we are not worried about any race condition between
> endpoint becoming disabled and io_submit. Is this true?
I don't think this holds, there will always be a windows where the
UDC can change state between reading the ep0 events and attempting I/O
on the other endpoint files.
Regards,
John
prev parent reply other threads:[~2021-12-02 14:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 17:04 USB: f_fs: Use Functionfs with kernel AIO Shang Shi
2021-12-02 14:46 ` John Keeping [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=YajcMBF7K1IaCkVe@donbot \
--to=john@metanate.com \
--cc=beddingfield@google.com \
--cc=linux-usb@vger.kernel.org \
--cc=shangshi@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.