Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5684324pxv; Wed, 28 Jul 2021 17:29:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweK55FPA0zeoC4bNWbCLer+zsjlNYR1KPw3F6boNELvJOuKCZtpR+8OTbIhwvy+tod2ah+ X-Received: by 2002:a17:907:75f3:: with SMTP id jz19mr142918ejc.69.1627518565656; Wed, 28 Jul 2021 17:29:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627518565; cv=none; d=google.com; s=arc-20160816; b=bT6Xap3py1VoIz3Tp44ViM+I1HqmeXZq6TBEeXdK/X3+tPXKpZzMM7mYl+CDnV+FXw Rb9XWfgSPUixyoevveyotOrHjxeCOY9nqPM2hYFLOPSWwLy+SU9hZoHKTDJLg12LYuri WBQDQ1f/0lv6YHPHZlgxiaEmdqfGnrFSr4MX0Xo/Amc2vjVPanfv1uhISnRLSRW/XEa/ /J+fXNRoV27sE55J2yxKa5oIsRAN/hDD6JFQmv3fpkLSAS/fKm2L8+nKgq6bBakAHkLE oryzMg7ryNWhOinKrzWDjGtjl4rTyf9u6oU0F1RMwulbmY7AQbBk4abgMg1z/h/YYgtq G0hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=3/+FeFYNqyKJR72zTgHgBvjmu1iMzo4ikFzned3cHKw=; b=qX13QFVSheugT9zqFR3tbeJ/3hKswFwyne4Aq3bCAUst6+PsVASRxWEKdVnx751erA CbtCTzcpOu8DmHaLt0Cf3slhAuMH0bI7cd+p26rMp9Hlzyn5U2Bjub9hLBBT30sXXe8l EKGhTzLQZ53eYWE5N8k3jpcKumZ8g7it/UcYk4kI+nJpqOx86u52M/FFJzQyY0oBlPkr j8WxZ6N3UVxi6HdhHWyDnjkDqYFOZWQZNwp2yu8SrMtEUsZCZm246iFOhd7h0GCNDTVI CGkYUyMkq18EEd5h1JqMMoe8O8uzMYvcONeXXE8mXbeMAA+BO5+TP3cwvdSBueP8C3Cm S39g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Vn8PB50J; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u12si1158046edx.354.2021.07.28.17.28.51; Wed, 28 Jul 2021 17:29:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Vn8PB50J; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232876AbhG2A2w (ORCPT + 99 others); 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