From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753275AbbDGQy1 (ORCPT ); Tue, 7 Apr 2015 12:54:27 -0400 Received: from smtp-out4.electric.net ([192.162.216.181]:55495 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751122AbbDGQyZ (ORCPT ); Tue, 7 Apr 2015 12:54:25 -0400 From: David Laight To: "'Robert Baldyga'" , Michal Nazarewicz , "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 Thread-Topic: [PATCH] usb: gadget: ffs: don't allow to open with O_NONBLOCK flag Thread-Index: AQHQbdVWwqNx4ROfR0yhLDai8fsCN51BynTg Date: Tue, 7 Apr 2015 16:52:56 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB15BBA@AcuExch.aculab.com> References: <1427881176-30522-1-git-send-email-r.baldyga@samsung.com> <551E2FBF.5070503@samsung.com> In-Reply-To: <551E2FBF.5070503@samsung.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t37GsWLs001650 From: Robert Baldyga > Hi Michal, > > On 04/01/2015 05:17 PM, Michal Nazarewicz wrote: > > On Wed, Apr 01 2015, Robert Baldyga 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. > > > > cant is a bit strong of a word here though. It can, but in a few > > cases it doesnt. > > > > 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). > > > > Im 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. Is that really necessary? I'm sure there are a lot of device drivers that ignore O_NONBLOCK. David {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I