From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754318AbbDGNo6 (ORCPT ); Tue, 7 Apr 2015 09:44:58 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:37411 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753637AbbDGNoz convert rfc822-to-8bit (ORCPT ); Tue, 7 Apr 2015 09:44:55 -0400 From: Michal Nazarewicz To: Robert Baldyga , 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 In-Reply-To: <551E2FBF.5070503@samsung.com> Organization: http://mina86.com/ References: <1427881176-30522-1-git-send-email-r.baldyga@samsung.com> <551E2FBF.5070503@samsung.com> User-Agent: Notmuch/0.19+53~g2e63a09 (http://notmuchmail.org) Emacs/25.0.50.1 (x86_64-unknown-linux-gnu) X-Face: PbkBB1w#)bOqd`iCe"Ds{e+!C7`pkC9a|f)Qo^BMQvy\q5x3?vDQJeN(DS?|-^$uMti[3D*#^_Ts"pU$jBQLq~Ud6iNwAw_r_o_4]|JO?]}P_}Nc&"p#D(ZgUb4uCNPe7~a[DbPG0T~!&c.y$Ur,=N4RT>]dNpd;KFrfMCylc}gc??'U2j,!8%xdD Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWbfGlUPDDHgE57V0jUupKjgIObY0PLrom9mH4dFRK4gmjPs41MxjOgAAACQElEQVQ4jW3TMWvbQBQHcBk1xE6WyALX1069oZBMlq+ouUwpEQQ6uRjttkWP4CmBgGM0BQLBdPFZYPsyFUo6uEtKDQ7oy/U96XR2Ux8ehH/89Z6enqxBcS7Lg81jmSuujrfCZcLI/TYYvbGj+jbgFpHJ/bqQAUISj8iLyu4LuFHJTosxsucO4jSDNE0Hq3hwK/ceQ5sx97b8LcUDsILfk+ovHkOIsMbBfg43VuQ5Ln9YAGCkUdKJoXR9EclFBhixy3EGVz1K6eEkhxCAkeMMnqoAhAKwhoUJkDrCqvbecaYINlFKSRS1i12VKH1XpUd4qxL876EkMcDvHj3s5RBajHHMlA5iK32e0C7VgG0RlzFPvoYHZLRmAC0BmNcBruhkE0KsMsbEc62ZwUJDxWUdMsMhVqovoT96i/DnX/ASvz/6hbCabELLk/6FF/8PNpPCGqcZTGFcBhhAaZZDbQPaAB3+KrWWy2XgbYDNIinkdWAFcCpraDE/knwe5DBqGmgzESl1p2E4MWAz0VUPgYYzmfWb9yS4vCvgsxJriNTHoIBz5YteBvg+VGISQWUqhMiByPIPpygeDBE6elD973xWwKkEiHZAHKjhuPsFnBuArrzxtakRcISv+XMIPl4aGBUJm8Emk7qBYU8IlgNEIpiJhk/No24jHwkKTFHDWfPniR4iw5vJaw2nzSjfq2zffcE/GDjRC2dn0J0XwPAbDL84TvaFCJEU4Oml9pRyEUhR3Cl2t01AoEjRbs0sYugp14/4X5n4pU4EHHnMAAAAAElFTkSuQmCC X-PGP: 50751FF4 X-PGP-FP: AC1F 5F5C D418 88F8 CC84 5858 2060 4012 5075 1FF4 X-Hashcash: 1:20:150407:gregkh@linuxfoundation.org::RBQzaW8Ro918KDwi:000000000000000000000000000000000000cFs X-Hashcash: 1:20:150407:r.baldyga@samsung.com::/D5VlgLEl/9MR1WG:00000000000000000000000000000000000000001WJ4 X-Hashcash: 1:20:150407:balbi@ti.com::oN0KTM6UirvKUhld:000002yRB X-Hashcash: 1:20:150407:linux-kernel@vger.kernel.org::zzcWDmfTr8OQNqF/:0000000000000000000000000000000003cj/ X-Hashcash: 1:20:150407:linux-usb@vger.kernel.org::TAnWrCToFiqtlyVm:000000000000000000000000000000000000946W Date: Tue, 07 Apr 2015 15:44:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 03 2015, Robert Baldyga wrote: > 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. >> >> ‘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. There is potentially a way to implement O_NONBLOCK for epfiles. This would require adding a new state property to epfile and moving completion structure from stack to epfile. In pseudo code we would have: epfile->state = FREE epfile_io(direction) if epfile->state == FREE queue(ep->req) epfile->state = PENDING if epfile->state == PENDING if O_NONBLOCK return -EAGAIN wait epfile->state = FINISHED // epfile->state == FINISHED copy data epfile->state = FREE return I think this is the only ‘technically correct’ solution, but I dunno if it is worth implementing especially since AIO is available. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +------ooO--(_)--Ooo--