Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753120AbaJPKb2 (ORCPT ); Thu, 16 Oct 2014 06:31:28 -0400 Received: from relay.parallels.com ([195.214.232.42]:48492 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753101AbaJPKb0 (ORCPT ); Thu, 16 Oct 2014 06:31:26 -0400 Message-ID: <543F9E75.2090509@parallels.com> Date: Thu, 16 Oct 2014 14:31:17 +0400 From: Maxim Patlasov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Miklos Szeredi CC: Linus Torvalds , Anand Avati , Linux Kernel Mailing List , Michael j Theall , fuse-devel Subject: Re: [PATCH 0/5] fuse: handle release synchronously (v4) References: <20140925120244.540.31506.stgit@dhcp-10-30-22-200.sw.ru> <20140930191933.GC5011@tucsk.piliscsaba.szeredi.hu> <542BE551.1010705@parallels.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.22.200] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Miklos, On 10/09/2014 12:14 PM, Miklos Szeredi wrote: > On Wed, Oct 1, 2014 at 1:28 PM, Maxim Patlasov wrote: >> Given those patches must die, do you have any ideas how to resolve that >> "spurious EBUSY" problem? > Check the "sync_release" branch of fuse: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git sync_release > > And same branch name for libfuse: > > git://git.code.sf.net/p/fuse/fuse sync_release > > What it does is send RELEASE from ->flush() after checking the > refcount of file (being careful about RCU accesses). > > Lightly tested, more testing, as well as review, is welcome. Thank you very much for efforts, highly appreciated! I've had a close look at your patches and found a few issues. Most of them can be easily fixed, but one puzzles me: the way how you detect last flush is not race free. Something as simple as: int main(int argc, char *argv[]) { int fd = open(argv[1], O_RDWR); fork(); } may easily dive into fuse_try_sync_release() concurrently and both observe file->f_count == 2. Then both return falling back to sending the release asynchronously. This makes sync/async behaviour unpredictable even for well-behaved applications which don't do any esoteric things like racing i/o with close or exiting while a descriptor is in-flight in a unix domain socket. I cannot see any way to recognise last flush without help of VFS layer, can you? Thanks, Maxim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/