linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: "Du\, Changbin" <changbin.du@intel.com>,
	Felipe Balbi <felipe.balbi@linux.intel.com>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	"gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rui.silva\@linaro.org" <rui.silva@linaro.org>,
	"k.opasiak\@samsung.com" <k.opasiak@samsung.com>,
	"lars\@metafoo.de" <lars@metafoo.de>,
	"linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: gadget: f_fs: report error if excess data received
Date: Wed, 18 May 2016 11:45:22 +0200	[thread overview]
Message-ID: <xa1tposjog25.fsf@mina86.com> (raw)
In-Reply-To: <0C18FE92A7765D4EB9EE5D38D86A563A05D30546@SHSMSX103.ccr.corp.intel.com>

On Tue, May 17 2016, Changbin Du wrote:
>> There appears to be no kfifo support for iov_iter though, so I just went
>> with a simple buffer.
>> 
>> I haven’t looked at the patch too carefully so this is an RFC rather
>> than an actual patch at this point.  It does compile at least.
>> 
>> Regardless, the more I thin about it, the more I’m under the impression
>> that the whole rounding up in f_fs was a mistake.  And the more I’m
>> leaning towards ignoring the excess data set by the host.
>> 
>> ---------- >8 ----------------------------------------------------------
>> Subject: usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests
>> 
>> f_fs rounds up read(2) requests to a multiple of a max packet size
>> which means that host may provide more data than user has space for.
>> So far, the excess data has been silently ignored.
>> 
>> This introduces a buffer for a tail of such requests so that they are
>> returned on next read instead of being ignored.
>> 
>
> Congratulations finally reach an agreement,

To be honest, if it was up to me, I would rip request size rounding up
out of the code.

> thanks Alan Stern and Michal.
> Here just have a comment - the buffered data need be dropped when the
> epfile is closed, because it means the session is terminated.

I blame that on sleep deprivation.  Another issue is what to do when
endpoint is disabled.  Should the buffer be cleared as soon as the
endpoint is disabled?  Or maybe when the endpoint is enabled again?  Or
maybe it should never be cleared?

If the buffer is cleared when endpoint is disabled, we again silently
drop data.  On the other hand, if we don’t do that, read() on the
endpoint will may succeed even if the configuration is disabled which
may be surprising for users.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

  reply	other threads:[~2016-05-18  9:45 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 10:19 [PATCH] usb: gadget: f_fs: report error if excess data received changbin.du
2016-05-11 10:59 ` Felipe Balbi
2016-05-11 12:30   ` Michal Nazarewicz
2016-05-12  4:25     ` Du, Changbin
2016-05-12  4:21   ` Du, Changbin
2016-05-12  6:52     ` Felipe Balbi
2016-05-12  7:30       ` Du, Changbin
2016-05-12  7:46         ` Felipe Balbi
2016-05-12  8:16           ` Du, Changbin
2016-05-12  9:15             ` Felipe Balbi
2016-05-12  9:22               ` Felipe Balbi
2016-05-12  9:51                 ` Du, Changbin
2016-05-12  9:39               ` Du, Changbin
2016-05-12 10:13                 ` Felipe Balbi
2016-05-12 10:14                 ` Felipe Balbi
2016-05-12 10:45                   ` Du, Changbin
2016-05-12 11:22                     ` Felipe Balbi
2016-05-13  5:52                       ` Du, Changbin
2016-05-13  6:36                         ` Felipe Balbi
2016-05-13 10:32                           ` Du, Changbin
2016-05-13 14:29                           ` Alan Stern
2016-05-14 20:39                             ` Michal Nazarewicz
2016-05-16 12:57                             ` Felipe Balbi
2016-05-16 13:08                               ` Michal Nazarewicz
2016-05-16 13:16                                 ` Felipe Balbi
2016-05-16 19:09                                   ` Michal Nazarewicz
2016-05-17  2:53                                     ` Du, Changbin
2016-05-18  9:45                                       ` Michal Nazarewicz [this message]
2016-05-18 10:15                                         ` Felipe Balbi
2016-05-18 13:39                                           ` Michal Nazarewicz
2016-05-19  2:54                                             ` Du, Changbin
2016-05-19  7:34                                               ` Michal Nazarewicz
2016-05-19  8:49                                                 ` Du, Changbin
2016-05-19  2:31                                           ` Du, Changbin
2016-05-16 16:05 ` Michal Nazarewicz
2016-05-16 16:27   ` Lars-Peter Clausen
2016-05-16 16:48     ` Michal Nazarewicz
2016-05-16 16:35   ` Krzysztof Opasiak

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=xa1tposjog25.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=changbin.du@intel.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=k.opasiak@samsung.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rui.silva@linaro.org \
    --cc=stern@rowland.harvard.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).