From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-db5eur01on0111.outbound.protection.outlook.com ([104.47.2.111]:2752 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751187AbdEaRvL (ORCPT ); Wed, 31 May 2017 13:51:11 -0400 Subject: Re: [fuse-devel] fuse: when are release requests queued? References: <87a860r0v9.fsf@thinkpad.rath.org> <87zidva9r3.fsf@vostro.rath.org> CC: "fuse-devel@lists.sourceforge.net" , To: Nikolaus Rath From: Maxim Patlasov Message-ID: <87eb44a9-359f-68eb-fe42-614a0d9c8193@virtuozzo.com> Date: Wed, 31 May 2017 10:50:57 -0700 MIME-Version: 1.0 In-Reply-To: <87zidva9r3.fsf@vostro.rath.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 05/29/2017 09:49 AM, Nikolaus Rath wrote: > Hi Maxim, > > On May 26 2017, Maxim Patlasov wrote: >> On 05/25/2017 04:08 PM, Nikolaus Rath wrote: >> >>> Hello, >>> >>> I am trying to debug a sporadic test failure in libfuse >>> (https://github.com/libfuse/libfuse/issues/157). >>> >>> >>> 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 has >>> 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). 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. > >>> Looking at fs/fuse/file.c, it looks as if fuse_release() directly calls >>> fuse_request_send_background() to send the request. But at that point I >>> can no longer follow the code. Is it possible for another request to >>> sneak in at this point? >> Yes, but not for that given fuse_file that we're closing now. > I assume that a fuse_file refers to the (formerly) opened file, right? > So e.g. a unlink() request for the same directly entry could still go > through before RELEASE has been transferred to the pending queue? Yes. But FUSE_UNLINK works on file path, it doesn't depend on fuse_file at all. Hence unlink request can go anytime. > > > Best, > -Nikolaus >