usb: gadget: f_fs: Fail waiting IO after eps disabled
Normally in epfile_io() and epfile_ioctl(), if the endpoint is
not enabled the system call will block waiting until the endpoint
is enabled. During a USB disconnect, the function's endpoints get
disabled, so that if an IO call occurs right after that, it would
perform the same blocking wait. From the kernel perspective this
is indistinguishable from an IO call happening after the function
is first initialized but not yet enabled. Hence a userspace
process would be blocked and unaware of the cable disconnection.
For userspace daemons such as ADB, this can be a problem since its
read/write threads cannot be reaped until the I/O call returns,
which won't happen until the cable is reconnected. In that case,
the previous pending read/write would proceed to get successfully
queued. In the case of a read, the previous read consumes data
meant for the new session, and in the case of a write, stale data
could be sent to the host.
To fix this, add a counter to keep track of the epfile's open status.
Upon the endpoint getting disabled mark the endpoint as invalid so as
to fail subsequent IOs until the epfile is fully closed. Returning
-ENODEV upon failure should allow the userspace process to close the
file, so that it can reopen and begin a new session.
Change-Id: I655ffdaa03485753431ff05dc521bf8d1b463ff1
Signed-off-by: Jack Pham <jackp@codeaurora.org>
1 file changed