lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0C18FE92A7765D4EB9EE5D38D86A563A05D30D56@SHSMSX103.ccr.corp.intel.com>
Date:	Thu, 19 May 2016 02:31:02 +0000
From:	"Du, Changbin" <changbin.du@...el.com>
To:	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Alan Stern <stern@...land.harvard.edu>
CC:	Al Viro <viro@...iv.linux.org.uk>,
	"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

> >> 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.
> 
> tough decision... but seems like clearing the buffer as soon as ep is
> disabled is the way to go.
> 
> --
> Balbi

I agree with Balbi, seems it is not easy to maintain the excess buffer... I was to
implement it at the beginning but I am not confident everything is done correctly.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ