[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0C18FE92A7765D4EB9EE5D38D86A563A05D2F03D@SHSMSX103.ccr.corp.intel.com>
Date: Thu, 12 May 2016 04:25:09 +0000
From: "Du, Changbin" <changbin.du@...el.com>
To: Michal Nazarewicz <mina86@...a86.com>,
Felipe Balbi <balbi@...nel.org>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"rui.silva@...aro.org" <rui.silva@...aro.org>,
"k.opasiak@...sung.com" <k.opasiak@...sung.com>,
"lars@...afoo.de" <lars@...afoo.de>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: gadget: f_fs: report error if excess data received
> On Wed, May 11 2016, Felipe Balbi wrote:
> > Also, returning -EOVERFLOW is not exactly correct here, because you'd
> > violate POSIX specification of read(), right ?
>
> Maybe we could piggyback on:
>
> EINVAL fd was created via a call to timerfd_create(2) and the
> wrong size buffer was given to read();
>
> But I kinda agree. I’m not sure how much we need to care about this
> instead of having user space round their buffers up to the nearest max
> packet size boundary.
>
> --
> Best regards
> ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
> «If at first you don’t succeed, give up skydiving»
This is a good idea that "having user space round their buffers". But kernel
Still cannot hide error silently. :)
Powered by blists - more mailing lists