From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:56839 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751034AbdEaTTW (ORCPT ); Wed, 31 May 2017 15:19:22 -0400 From: Nikolaus Rath To: Maxim Patlasov , fuse-devel , 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> Date: Wed, 31 May 2017 12:19:19 -0700 In-Reply-To: <87eb44a9-359f-68eb-fe42-614a0d9c8193@virtuozzo.com> (Maxim Patlasov's message of "Wed, 31 May 2017 10:50:57 -0700") Message-ID: <87mv9svnpk.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: >>>> Can someone tell me at which point the fuse kernel module will send a >>>> RELEASE request to userspace? >>> >>> Anytime after fuse_release(). It only puts request to background >>> queue. Later, the request will be transferred to pending queue. And >>> later, the userspace will fetch it by fuse_dev_do_read(). >>> >>>> Is it possible that this is delayed until >>>> after the close() syscall for the last fd has returned and userspace h= as >>>> submitted a different fuse request for the same fs? >>> I think it's possible. See how flush_bg_queue() do nothing if >>> fc->active_background > fc->max_background. >> Thanks Maxim! Not sure what I'd do with these issues without you :-). >> >> >> Is there a way to deliberate trigger this behavior for debugging? For >> example, is there a kernel equivalent of sleep(1) that I could put into >> fuse_release()? > > schedule_timeout_interruptible(HZ). Hmm. I made the following change in linux 4.10: diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 2401c5..3568a8 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -252,6 +252,9 @@ void fuse_release_common(struct file *file, int opcode) if (unlikely(!ff)) return; =20 + // Wait a little to force race condition in userspace + schedule_timeout_interruptible(1); + req =3D ff->reserved_req; fuse_prepare_release(ff, file->f_flags, opcode); =20 But when doing e.g. "echo test > newfile", the RELEASE request still comes right away (judging from the libfuse debugging output). Do I need to do something else? > But it's better to instrument fuse > userspace to postpone processing some i/o requests. Then you'll keep > fc->active_background > fc->max_background for a while. During that > period fuse_release may succeed with FUSE_RELEASE queued, but not > passed to the userspace. Then you cat try to sneak another request -- > something not involving fuse background queue. I don't know.. why is this better? It seems a lot more complicated. I need to generate the extra request, add some switch to tell libfuse when to start processing again, synchronize this with sneaking in the other request... 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