From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EDDACD68E4 for ; Tue, 10 Oct 2023 02:35:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1441900AbjJJCfX (ORCPT ); Mon, 9 Oct 2023 22:35:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1441879AbjJJCfU (ORCPT ); Mon, 9 Oct 2023 22:35:20 -0400 Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A1CA9C for ; Mon, 9 Oct 2023 19:35:18 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|kjlx@templeofstupid.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 00D2D9016BA for ; Tue, 10 Oct 2023 02:35:18 +0000 (UTC) Received: from pdx1-sub0-mail-a302.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 949AB90175A for ; Tue, 10 Oct 2023 02:35:17 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1696905317; a=rsa-sha256; cv=none; b=TIBN15xECxQ2rocZAfCCJ3kLZqBDlguB7juC/JBr8XFZUp/2KyG/FuBs6DFUgETh0WlXCV kF28uchtQr221VgY6RB2cl28qvOgFnR32eNxQ5TzHvXKceCBUOnL8YJj/9re9ky64ZVsc6 88B0g3RFnTtAO/Kh3qRoZ/twIo9z4PFsUXNI3tBt8VrngB3i8nbhOyE0i3ZAGfCeFiAVc0 kBkonKB54nwhOw6wmIEhaeZJcs6V9DCfmC59qybivFa4U/q0XD6wav1Cnv7yPHPLHCWdNI rZ103BZMu1wviYxsgF9r6PAXHJ5KZMRQARxipC3u9Hj/EYBnQW2xkXPD0+pDeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1696905317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1JVOiXTXOZdbi2lb57a4eTH6VFOz8zWW7VpahK0e+lI=; b=b3dLXMELe5+1/pcW233h03TAPrkolGfWF0iQkXxgi+/KN/sI8uefa65VKLobtyYX5Maa1L ATlcfFdUYuAKjt0FGFbyXcWAhO7/jRVDIvnxBN59rWDZDZBpwYnlf9Sbjaklrqbjz/+f1C M6HQqFx+54Ea0Y2ploqeL+Q4VDi1DbVPXalUZKsAZ9a6UC+u3mjmi0UxsIvpfEeMCAVT39 JmkCQmoe4I+iwgrdS1YJNqCppCNd7wOeP7CsreghxeWgX9fWKls5pA9zAU0eqjuHD3lDSM T3f67yHJFGmuSwe0V+0Uwdh5bhsmh0AzstkZ/j1oNdmJLW6ekbbWXOO/Iz1yjw== ARC-Authentication-Results: i=1; rspamd-7d5dc8fd68-njhvv; auth=pass smtp.auth=dreamhost smtp.mailfrom=kjlx@templeofstupid.com X-Sender-Id: dreamhost|x-authsender|kjlx@templeofstupid.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|kjlx@templeofstupid.com X-MailChannels-Auth-Id: dreamhost X-White-Bitter: 67d044902de176ed_1696905317826_487601250 X-MC-Loop-Signature: 1696905317826:1070752151 X-MC-Ingress-Time: 1696905317826 Received: from pdx1-sub0-mail-a302.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.126.222.25 (trex/6.9.1); Tue, 10 Oct 2023 02:35:17 +0000 Received: from kmjvbox (c-73-231-176-24.hsd1.ca.comcast.net [73.231.176.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kjlx@templeofstupid.com) by pdx1-sub0-mail-a302.dreamhost.com (Postfix) with ESMTPSA id 4S4KkY2V3pznk for ; Mon, 9 Oct 2023 19:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=templeofstupid.com; s=dreamhost; t=1696905317; bh=1JVOiXTXOZdbi2lb57a4eTH6VFOz8zWW7VpahK0e+lI=; h=Date:From:To:Cc:Subject:Content-Type; b=Nokg/ZsKA47dB1+MZhw8eHTIA0xzSOvIGoHWMdSozdnUnX+7DceMMaKgdjlAVTK1c nj54Z+kS0EpzvLFBp5hb2FlGOXiebgCK8HnvwRA8H0UknkqOtTzlCkQwKSuwK1C8BN tNVlbt/fXXvCkQRTwaH3RWb1Ys9LCpe2+NOvlm5mwbedJLjY3KL24nsA2pwML30eZZ 45cQqrAVEABS3n0FWulSbKp/olZmtNDssWAf0GKKxgcgWErMVMuTF9SEIqYptDKFL3 1QU5HbKgIjXuuHWeCHJKARrJ7qqI9Pa74O0/eyN6XDcB43HJd6YzxC2W1fqLKmtez5 50Ip4+IoewrXQ== Received: from johansen (uid 1000) (envelope-from kjlx@templeofstupid.com) id e00f8 by kmjvbox (DragonFly Mail Agent v0.12); Mon, 09 Oct 2023 19:35:12 -0700 Date: Mon, 9 Oct 2023 19:35:12 -0700 From: Krister Johansen To: Bernd Schubert Cc: Krister Johansen , Miklos Szeredi , linux-fsdevel@vger.kernel.org, Miklos Szeredi , linux-kernel@vger.kernel.org, German Maglione , Greg Kurz , Max Reitz Subject: Re: [resend PATCH v2 2/2] fuse: ensure that submounts lookup their parent Message-ID: <20231010023512.GB1983@templeofstupid.com> References: <45778432fba32dce1fb1f5fd13272c89c95c3f52.1696043833.git.kjlx@templeofstupid.com> <3187f942-dcf0-4b2f-a106-0eb5d5a33949@fastmail.fm> <20231007004107.GA1967@templeofstupid.com> <968148ad-787e-4ccb-9d84-f32b5da88517@fastmail.fm> <20231009171525.GA1973@templeofstupid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 09, 2023 at 08:43:02PM +0200, Bernd Schubert wrote: > On 10/9/23 19:15, Krister Johansen wrote: > > Thanks, I had forgotten that d_make_root() would call iput() for me if > > d_alloc_anon() fails. Let me restate this to suggest that I account the > > nlookup to the parent if fuse_dentry_revalidate_lookup() or fuse_iget() > > fail instead. Does that sound right? > > Hmm, so server/daemon side uses the lookup count to have an inode reference > - are you sure that parent is the right inode for the forget call? And what > is the probability for such failures? I.e. is that performance critical? > Wouldn't be much simpler and clearer to just avoid and doubt and to send an > immediate forget? Yeah, the server / daemon side need to track the lookup count so that it knows when it can close the fd for the file on the server-side. (At least for virtiofsd, anyway.). The reason I had avoided doing the forget in the submount code is that it needs a forget linkage in order to call fuse_queue_forget(). One of these is allocated by fuse_alloc_inode(). A well formed parent should always have one. However, if the fuse_iget() for the submount root fails, then there's no linkage to borrow from the new inode. The code could always call fuse_alloc_forget() directly, like is done elsewhere. I thought it might be hard to get the memory for this allocation if fuse_iget() also can't allocate enough, but I could move the allocation earlier in the function and just free it if it's not used. I'm not confident that would reduce the amount of code in the function, but if you'd find it clearer, I'm happy to modify it accordingly. -K