From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:47753 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbdEaUbL (ORCPT ); Wed, 31 May 2017 16:31:11 -0400 From: Nikolaus Rath To: Maxim Patlasov Cc: "fuse-devel\@lists.sourceforge.net" , linux-fsdevel Subject: Re: [fuse-devel] fuse: when are release requests queued? References: <87a860r0v9.fsf@thinkpad.rath.org> <87zidva9r3.fsf@vostro.rath.org> <87eb44a9-359f-68eb-fe42-614a0d9c8193@virtuozzo.com> <87mv9svnpk.fsf@thinkpad.rath.org> <87inkgvmp0.fsf@thinkpad.rath.org> <0ad44a48-5b0f-ee1d-ccdf-f617378c07e6@virtuozzo.com> Date: Wed, 31 May 2017 13:31:08 -0700 In-Reply-To: <0ad44a48-5b0f-ee1d-ccdf-f617378c07e6@virtuozzo.com> (Maxim Patlasov's message of "Wed, 31 May 2017 13:23:13 -0700") Message-ID: <87fufkvkdv.fsf@thinkpad.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On May 31 2017, Maxim Patlasov wrote: >> I do not fully understand the difference you describe. What I would like >> to construct is the following scenario: >> >> 1. Userspace calls close() >> 2. Userspace close() returns >> 3. Userspace calls unlink() >> 4. Userspace unlink() returns >> 5. libfuse reads UNLINK request from kernel pipe >> 6. libfuse reads RELEASE request from kernel pipe >> >> What would be the simplest way to do that? > > I would try to keep fc->active_background elevated somehow. For > example you add sleep(1) for every incoming write request to libfuse > and serialize processing them. Then you generate enough writes to > achieve fc->max_background. If you call close() now, and if it really > ends up in last __fput(), corresponding FUSE_RELEASE will sit in > background queue for long while (as many seconds as # elements in the > queue). But close() from your 2. will return much earlier because it > doesn't wait for completion of FUSE_RELEASE. Hence unlink() might > succeed. Ah, got it now, thanks! Wouldn't be a simpler solution be to just patch the kernel module to *always* put FUSE_RELEASE requests into the background queue, so that I don't have to manually keep fc->active_background elevated? I just can't seem to find the code that does this check... I would expect it in fuse_file_put(), but the condition in there does not seem to look at the number of background requests at all. Best, -Nikolaus --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB