From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Baldyga Subject: Re: commit "usb: gadget: ffs: add eventfd notification about ffs events" Date: Thu, 19 Feb 2015 07:35:25 +0100 Message-ID: <54E5842D.7080908@samsung.com> References: <20150218173639.GA18641@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Al Viro , Michal Nazarewicz , Felipe Balbi , linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from mailout3.w1.samsung.com ([210.118.77.13]:50887 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751169AbbBSGfw (ORCPT ); Thu, 19 Feb 2015 01:35:52 -0500 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NK000BHHAIHEO90@mailout3.w1.samsung.com> for linux-fsdevel@vger.kernel.org; Thu, 19 Feb 2015 06:39:53 +0000 (GMT) In-reply-to: <20150218173639.GA18641@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Christoph, On 02/18/2015 06:36 PM, Christoph Hellwig wrote: > Hi Robert, > > your above commit pokes into kiocb internals it really should not, and > it breaks my patchset that's been on the -fsdevel list which makes most > of the kiocb guts private to fs/aio.c. > > First please Cc patches like that to linux-fsdevel. Second I don't > think the logic in it is correct. You should not disable your own > notifications based on how aio works, but do it unconditionally. What > was the reason to disable the eventfd notification if there is an aio > one as well? > Sometimes we would like to have one endpoint handled in separate thread. It could have its own eventfd, which notifies only about events on its own requests. We don't want to notify main event loop in main thread about these events, because it doesn't make sense. The another example is using AIO hidden under synchronous API to have timeout feature. We submit AIO transfer with own eventfd, we select() on this eventfd with given timeout, and if timeout expired we cancel transfer. Then we don't want to notify main event loop about async transfer completion, because from users point of view performed operation looks like synchronous. Most of requests will be handled using ffs eventfd, but when we supply another one to selected transfer, we rather don't want to have notification on the first one. Robert