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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97DCFC4338F for ; Thu, 29 Jul 2021 00:28:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F8D860F59 for ; Thu, 29 Jul 2021 00:28:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232876AbhG2A2w (ORCPT ); Wed, 28 Jul 2021 20:28:52 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50038 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232727AbhG2A2w (ORCPT ); Wed, 28 Jul 2021 20:28:52 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 93C9722305; Thu, 29 Jul 2021 00:28:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1627518528; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3/+FeFYNqyKJR72zTgHgBvjmu1iMzo4ikFzned3cHKw=; b=Vn8PB50JCHsww87su5TaRlPcYxZ6FYbGuvjVLjMneTG1e1RAEHtdDTM0hauvqXUfwAaA0H m6Aw/IgQ3PQFCrOiYnlXQEjmuKMMdHipzeQs1Zq/Pj0w48p9gwOn+61/guY2MqUOn/awLa SPwvCSlhStVoc8vSOEXSComEy3LZJ8U= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1627518528; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3/+FeFYNqyKJR72zTgHgBvjmu1iMzo4ikFzned3cHKw=; b=QNudFvSon7m5IeyThiCJxZ2pOK4ftpUGRrDFkCK4yi3lvUFu9md7ByXCzpgccgX5zNnPuj FYgvJMj+yxdjJoAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2C1F413ADC; Thu, 29 Jul 2021 00:28:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id j9PONjz2AWHwewAAMHmgww (envelope-from ); Thu, 29 Jul 2021 00:28:44 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Amir Goldstein" Cc: "Christoph Hellwig" , "Josef Bacik" , "J. Bruce Fields" , "Chuck Lever" , "Chris Mason" , "David Sterba" , "Alexander Viro" , "linux-fsdevel" , "Linux NFS Mailing List" , "Linux Btrfs" , "Miklos Szeredi" Subject: Re: [PATCH 07/11] exportfs: Allow filehandle lookup to cross internal mount points. In-reply-to: References: <162742539595.32498.13687924366155737575.stgit@noble.brown>, <162742546554.32498.9309110546560807513.stgit@noble.brown>, Date: Thu, 29 Jul 2021 10:28:42 +1000 Message-id: <162751852209.21659.13294658501847453542@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, 28 Jul 2021, Amir Goldstein wrote: > On Wed, Jul 28, 2021 at 1:44 AM NeilBrown wrote: > > > > When a filesystem has internal mounts, it controls the filehandles > > across all those mounts (subvols) in the filesystem. So it is useful to > > be able to look up a filehandle again one mount, and get a result which > > is in a different mount (part of the same overall file system). > > > > This patch makes that possible by changing export_decode_fh() and > > export_decode_fh_raw() to take a vfsmount pointer by reference, and > > possibly change the vfsmount pointed to before returning. > > > > The core of the change is in reconnect_path() which now not only checks > > that the dentry is fully connected, but also that the vfsmnt reported > > has the same 'dev' (reported by vfs_getattr) as the dentry. > > If it doesn't, we walk up the dparent() chain to find the highest place > > where the dev changes without there being a mount point, and trigger an > > automount there. > > > > As no filesystems yet provide local-mounts, this does not yet change any > > behaviour. > > > > In exportfs_decode_fh_raw() we previously tested for DCACHE_DISCONNECT > > before calling reconnect_path(). That test is dropped. It was only a > > minor optimisation and is now inconvenient. > > > > The change in overlayfs needs more careful thought than I have yet given > > it. > > Just note that overlayfs does not support following auto mounts in layers. > See ovl_dentry_weird(). ovl_lookup() fails if it finds such a dentry. > So I think you need to make sure that the vfsmount was not crossed > when decoding an overlayfs real fh. Sounds sensible - thanks. Does this mean that my change would cause problems for people using overlayfs with a btrfs lower layer? > > Apart from that, I think that your new feature should be opt-in w.r.t > the exportfs_decode_fh() vfs api and that overlayfs should not opt-in > for the cross mount decode. I did consider making it opt-in, but it is easy enough for the caller to ignore the changed vfsmount, and only one (of 4) callers that it really makes a difference for. I will review the overlayfs in light of these comments. Thanks, NeilBrown