From patchwork Wed May 31 19:19:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nikolaus Rath X-Patchwork-Id: 9757985 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5FA6560390 for ; Wed, 31 May 2017 19:19:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4207320243 for ; Wed, 31 May 2017 19:19:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3328320700; Wed, 31 May 2017 19:19:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2C48520243 for ; Wed, 31 May 2017 19:19:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751041AbdEaTTX (ORCPT ); Wed, 31 May 2017 15:19:23 -0400 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 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DF07120A5A; Wed, 31 May 2017 15:19:21 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 31 May 2017 15:19:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=0aTqEgUir4PLzJVAeYT6oa9zAccnbYpfzv15EcXAEXg=; b=g8PVxEdg CehILtCCXJYQrOQ5qKZMUtfLQ7zJd/ajyYm/5h+6WX8s2tAKySBrQhVfj16RMRsT JuXr1dpUovaGty1sQgKfTOTBiA+XXLXUG7vQfTexDrrdNnKEYYApm+f+vpMFWAqr qYabAYkGKmmebgUJRtR5C/eDLIcCp+MXl53e0aysRXf/G4Cy//7hEiFT4Bysm7zp JA/A/P0uvrZ+B4lHs7maLFK3B9cwdNfO5R7aE+nyd+DKNgRHdmj/QjtpueCu3Mt1 o0qkRSAQJYWzmNHzCPEWNJlvDhvIM2Ger03bgPkhtLGZx1YdbI++tD9lGzpulMzG SpMg1xsiZnnhlA== X-ME-Sender: X-Sasl-enc: ZyGDKjfsI0ENopqB19vV1JGi9mgW4mVSYRnMatLj1fCm 1496258361 Received: from ebox.rath.org (ebox.rath.org [45.79.69.51]) by mail.messagingengine.com (Postfix) with ESMTPA id 97BD72445F; Wed, 31 May 2017 15:19:21 -0400 (EDT) Received: from thinkpad.rath.org (thinkpad [192.168.12.2]) by ebox.rath.org (Postfix) with ESMTPS id D2E534E0; Wed, 31 May 2017 19:19:20 +0000 (UTC) Received: by thinkpad.rath.org (Postfix, from userid 1000) id 68B02BFCC0; Wed, 31 May 2017 12:19:20 -0700 (PDT) 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> Mail-Copies-To: never Mail-Followup-To: Maxim Patlasov , fuse-devel , linux-fsdevel 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> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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). Hmm. I made the following change in linux 4.10: 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 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; + // Wait a little to force race condition in userspace + schedule_timeout_interruptible(1); + req = ff->reserved_req; fuse_prepare_release(ff, file->f_flags, opcode);