From: Robert Baldyga <r.baldyga@samsung.com>
To: Michal Nazarewicz <mina86@mina86.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: Fri, 03 Apr 2015 08:14:23 +0200 [thread overview]
Message-ID: <551E2FBF.5070503@samsung.com> (raw)
In-Reply-To: <xa1t8uebc1yr.fsf@mina86.com>
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. Everything is up to host.
When we can open file with O_NONBLOCK we expect that non-blocking API
will work, which isn't true in our case. Then it causes problems like
this one: https://lkml.org/lkml/2015/3/31/688
However it looks like you're right that my patch can cause ABI break, so
it shouldn't be applied.
Do you have any idea what can we do about that?
Best regards,
Robert Baldyga
>
>> Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
>> ---
>> drivers/usb/gadget/function/f_fs.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
>> index 175c995..1014911 100644
>> --- a/drivers/usb/gadget/function/f_fs.c
>> +++ b/drivers/usb/gadget/function/f_fs.c
>> @@ -538,6 +538,14 @@ static int ffs_ep0_open(struct inode *inode, struct file *file)
>> if (unlikely(ffs->state == FFS_CLOSING))
>> return -EBUSY;
>>
>> + /*
>> + * We are not supporting 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.
>> + */
>> + if (unlikely(file->f_flags & O_NONBLOCK))
>> + return -EWOULDBLOCK;
>> +
>> file->private_data = ffs;
>> ffs_data_opened(ffs);
>>
>> @@ -874,6 +882,14 @@ ffs_epfile_open(struct inode *inode, struct file *file)
>> if (WARN_ON(epfile->ffs->state != FFS_ACTIVE))
>> return -ENODEV;
>>
>> + /*
>> + * We are not supporting 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.
>> + */
>> + if (unlikely(file->f_flags & O_NONBLOCK))
>> + return -EWOULDBLOCK;
>> +
>> file->private_data = epfile;
>> ffs_data_opened(epfile->ffs);
>>
>> --
>> 1.9.1
>>
>
next prev parent reply other threads:[~2015-04-03 6:14 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 [this message]
2015-04-07 13:44 ` Michal Nazarewicz
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=551E2FBF.5070503@samsung.com \
--to=r.baldyga@samsung.com \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mina86@mina86.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox