From: Michal Nazarewicz <mina86@mina86.com>
To: Robert Baldyga <r.baldyga@samsung.com>, balbi@ti.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: ffs: don't allow to open with O_NONBLOCK flag
Date: Tue, 07 Apr 2015 15:44:51 +0200 [thread overview]
Message-ID: <xa1tlhi49hnw.fsf@mina86.com> (raw)
In-Reply-To: <551E2FBF.5070503@samsung.com>
On Fri, Apr 03 2015, Robert Baldyga <r.baldyga@samsung.com> wrote:
> Hi Michal,
>
> On 04/01/2015 05:17 PM, Michal Nazarewicz wrote:
>> On Wed, Apr 01 2015, Robert Baldyga <r.baldyga@samsung.com> wrote:
>>> FunctionFS can't support O_NONBLOCK because read/write operatons are
>>> directly translated into USB requests which are asynchoronous, so we
>>> can't know how long we will have to wait for request completion. For
>>> this reason in case of open with O_NONBLOCK flag we return
>>> -EWOULDBLOCK.
>>
>> ‘can’t’ is a bit strong of a word here though. It can, but in a few
>> cases it doesn’t.
>>
>> It kinda saddens me that this undoes all the lines of code that were put
>> into the file to support O_NONBLOCK (e.g. FFS_NO_SETUP path of
>> ffs_ep0_read).
>>
>> I’m also worried this may break existing applications which, for better
>> or worse, open the file with O_NONBLOCK.
>>
>> Most importantly though, this does not stop users from using fcntl to
>> set O_NONBLOCK, so if you really want to stop O_NONBLOCK from being set,
>> that path should be checked as well (if possible).
>
> I want rather to inform users that non-blocking i/o wouldn't work for
> epfiles. Indeed we can handle O_NONBLOCK for ep0 (for the same reason we
> can have poll), but for other epfiles there is no way to check if
> read/write operation can end up in short time.
There is potentially a way to implement O_NONBLOCK for epfiles. This
would require adding a new state property to epfile and moving
completion structure from stack to epfile. In pseudo code we would
have:
epfile->state = FREE
epfile_io(direction)
if epfile->state == FREE
queue(ep->req)
epfile->state = PENDING
if epfile->state == PENDING
if O_NONBLOCK
return -EAGAIN
wait
epfile->state = FINISHED
// epfile->state == FINISHED
copy data
epfile->state = FREE
return
I think this is the only ‘technically correct’ solution, but I dunno if
it is worth implementing especially since AIO is available.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--
next prev parent reply other threads:[~2015-04-07 13:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 9:39 [PATCH] usb: gadget: ffs: don't allow to open with O_NONBLOCK flag Robert Baldyga
2015-04-01 15:17 ` Michal Nazarewicz
2015-04-03 6:14 ` Robert Baldyga
2015-04-07 13:44 ` Michal Nazarewicz [this message]
2015-04-07 16:52 ` David Laight
2015-04-07 19:48 ` Michal Nazarewicz
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=xa1tlhi49hnw.fsf@mina86.com \
--to=mina86@mina86.com \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=r.baldyga@samsung.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.