Message ID | 20221207084309.8499-1-richard@nod.at |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp59659wrr; Wed, 7 Dec 2022 00:45:47 -0800 (PST) X-Google-Smtp-Source: AA0mqf7gTxrTgaKk03MaKAUovCgGCqYuz78mxIMEeGEMCO5bR5q1z43JC7e3+EgsZqDRFuBFf7K5 X-Received: by 2002:a17:90a:c590:b0:219:56eb:6c19 with SMTP id l16-20020a17090ac59000b0021956eb6c19mr40918368pjt.29.1670402746655; Wed, 07 Dec 2022 00:45:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670402746; cv=none; d=google.com; s=arc-20160816; b=z9xMePYdDliQgdu1vTGsJi1fAElJhPTK24KPN+0cukSYU08D5ufZF2UQ40EASacEIH NgnKxV6HMC5nyrQKCsR8wioffp3bOGWWeCpQkf0viE50s4kjAFFMnzbQ8FKKZkHmuCec +mCu5oprQybXfoUTYRZq701JE/n+ojnT+8Xt95Kw2EUyJNGdQ2Txi01xsz0GU+DOfi5E S0ks2hzIRNMvEGGknCSpG8n5Y7RYD0NvNfou/jPPdGlTVvk1AoJS3LlaBT7HSrOEAYuW P+NKbPrcepOS+qZBu6uB74UZf9fV6Njdt1y1g7efQOd3pLyCDXhHzpMytmmNlQnAsr2Z Jvsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Ze6hc+gquij1LlTckabofi5fW2FytK5/p3tJfBoaYVg=; b=RsH6hk72l11Kmvb0e1rGX4PEnUzcJUTogyC0Hv26eiCy/2+LhrI4GccUaU2tfhmwVW sM8gtAGTpFpgyEGwwoAIL+piPxFdRse/IjmJyPwuyWo0PgvyU7MP8hvyBz4i/uTwqBQs AQ6D3k+DsORp17pcG3pXyv1VSM99oSnXczJO1i9Lb+vzQJ0KOu7bfwLx5s6mLrgCXPAx O5+spoNfCqWsdmn5txtVh2I7uDHKAETMA9zpHPRjX3hmN757I+wf4PkA+jyG3sIPDxVs 6B3CfvC0wk8NM1whOxI6QYFZtCTYuYQWJKGLUvJ0sFzLRF/BuszsEQAL7Y75pyR6pgjC lUTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pb1-20020a17090b3c0100b002189d2ba5a3si903377pjb.133.2022.12.07.00.45.33; Wed, 07 Dec 2022 00:45:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229872AbiLGIni (ORCPT <rfc822;b08248@gmail.com> + 99 others); Wed, 7 Dec 2022 03:43:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbiLGIna (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Dec 2022 03:43:30 -0500 Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99076A44E; Wed, 7 Dec 2022 00:43:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id C3E8F615CA0B; Wed, 7 Dec 2022 09:43:24 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SlEnw1moQhMV; Wed, 7 Dec 2022 09:43:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 0D44F64BA9D7; Wed, 7 Dec 2022 09:43:24 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uI7tyEAeGD_P; Wed, 7 Dec 2022 09:43:23 +0100 (CET) Received: from blindfold.corp.sigma-star.at (unknown [82.150.214.1]) by lithops.sigma-star.at (Postfix) with ESMTPSA id 647F164BA9AE; Wed, 7 Dec 2022 09:43:23 +0100 (CET) From: Richard Weinberger <richard@nod.at> To: linux-nfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, jlayton@kernel.org, chuck.lever@oracle.com, anna@kernel.org, trond.myklebust@hammerspace.com, viro@zeniv.linux.org.uk, raven@themaw.net, chris.chilvers@appsbroker.com, david.young@appsbroker.com, luis.turcitu@appsbroker.com, david@sigma-star.at, benmaynard@google.com, Richard Weinberger <richard@nod.at> Subject: [PATCH 0/3 v2] NFS: NFSD: Allow crossing mounts when re-exporting Date: Wed, 7 Dec 2022 09:43:06 +0100 Message-Id: <20221207084309.8499-1-richard@nod.at> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751544230432208753?= X-GMAIL-MSGID: =?utf-8?q?1751544230432208753?= |
Series |
NFS: NFSD: Allow crossing mounts when re-exporting
|
|
Message
Richard Weinberger
Dec. 7, 2022, 8:43 a.m. UTC
Currently when re-exporting a NFS share the NFS cross mount feature does not work [0]. This patch series outlines an approach to address the problem. Crossing mounts does not work for two reasons: 1. As soon the NFS client (on the re-exporting server) sees a different filesystem id, it installs an automount. That way the other filesystem will be mounted automatically when someone enters the directory. But the cross mount logic of KNFS does not know about automount. This patch series addresses the problem and teach both KNFSD and the exportfs logic of NFS to deal with automount. 2. When KNFSD detects crossing of a mount point, it asks rpc.mountd to install a new export for the target mount point. Beside of authentication rpc.mountd also has to find a filesystem id for the new export. Is the to be exported filesystem a NFS share, rpc.mountd cannot derive a filesystem id from it and refuses to export. In the logs you'll see errors such as: mountd: Cannot export /srv/nfs/vol0, possibly unsupported filesystem or fsid= required To deal with that I've changed rpc.mountd to use generate and store fsids [1]. Since the kernel side of my changes did change for a long time I decided to try upstreaming it first. A 3rd iteration of my rpc.mountd will happen soon. [0] https://marc.info/?l=linux-nfs&m=161653016627277&w=2 [1] https://lore.kernel.org/linux-nfs/20220217131531.2890-1-richard@nod.at/ Changes since v1: https://lore.kernel.org/linux-nfs/20221117191151.14262-1-richard@nod.at/ - Use LOOKUP_AUTOMOUNT only when NFSEXP_CROSSMOUNT is set (Jeff Layton) Richard Weinberger (3): NFSD: Teach nfsd_mountpoint() auto mounts fs: namei: Allow follow_down() to uncover auto mounts NFS: nfs_encode_fh: Remove S_AUTOMOUNT check fs/namei.c | 6 +++--- fs/nfs/export.c | 2 +- fs/nfsd/vfs.c | 8 ++++++-- include/linux/namei.h | 2 +- 4 files changed, 11 insertions(+), 7 deletions(-)
Comments
> On Dec 7, 2022, at 3:43 AM, Richard Weinberger <richard@nod.at> wrote: > > Currently when re-exporting a NFS share the NFS cross mount feature does > not work [0]. > This patch series outlines an approach to address the problem. > > Crossing mounts does not work for two reasons: > > 1. As soon the NFS client (on the re-exporting server) sees a different > filesystem id, it installs an automount. That way the other filesystem > will be mounted automatically when someone enters the directory. > But the cross mount logic of KNFS does not know about automount. > This patch series addresses the problem and teach both KNFSD > and the exportfs logic of NFS to deal with automount. > > 2. When KNFSD detects crossing of a mount point, it asks rpc.mountd to install > a new export for the target mount point. Beside of authentication rpc.mountd > also has to find a filesystem id for the new export. Is the to be exported > filesystem a NFS share, rpc.mountd cannot derive a filesystem id from it and > refuses to export. In the logs you'll see errors such as: > > mountd: Cannot export /srv/nfs/vol0, possibly unsupported filesystem or fsid= required > > To deal with that I've changed rpc.mountd to use generate and store fsids [1]. > Since the kernel side of my changes did change for a long time I decided to > try upstreaming it first. > A 3rd iteration of my rpc.mountd will happen soon. > > [0] https://marc.info/?l=linux-nfs&m=161653016627277&w=2 > [1] https://lore.kernel.org/linux-nfs/20220217131531.2890-1-richard@nod.at/ > > Changes since v1: > https://lore.kernel.org/linux-nfs/20221117191151.14262-1-richard@nod.at/ > > - Use LOOKUP_AUTOMOUNT only when NFSEXP_CROSSMOUNT is set (Jeff Layton) > > Richard Weinberger (3): > NFSD: Teach nfsd_mountpoint() auto mounts > fs: namei: Allow follow_down() to uncover auto mounts > NFS: nfs_encode_fh: Remove S_AUTOMOUNT check > > fs/namei.c | 6 +++--- > fs/nfs/export.c | 2 +- > fs/nfsd/vfs.c | 8 ++++++-- > include/linux/namei.h | 2 +- > 4 files changed, 11 insertions(+), 7 deletions(-) > > -- > 2.26.2 > This series is a bit late for inclusion in v6.2. The next opportunity will be v6.3 in a couple of months. I prefer to have a "final" version of patches by -rc5. I'm waiting for review comments on v2 of this series. -- Chuck Lever
----- Ursprüngliche Mail ----- > Von: "chuck lever" <chuck.lever@oracle.com> >> Richard Weinberger (3): >> NFSD: Teach nfsd_mountpoint() auto mounts >> fs: namei: Allow follow_down() to uncover auto mounts >> NFS: nfs_encode_fh: Remove S_AUTOMOUNT check >> >> fs/namei.c | 6 +++--- >> fs/nfs/export.c | 2 +- >> fs/nfsd/vfs.c | 8 ++++++-- >> include/linux/namei.h | 2 +- >> 4 files changed, 11 insertions(+), 7 deletions(-) >> >> -- >> 2.26.2 >> > > This series is a bit late for inclusion in v6.2. The next opportunity > will be v6.3 in a couple of months. I prefer to have a "final" version > of patches by -rc5. > > I'm waiting for review comments on v2 of this series. Ok! Do you want me to resend the series in any case by v6.2-rc5 or only if new comments arise? Thanks, //richard
> On Dec 10, 2022, at 4:52 PM, Richard Weinberger <richard@nod.at> wrote: > > ----- Ursprüngliche Mail ----- >> Von: "chuck lever" <chuck.lever@oracle.com> >>> Richard Weinberger (3): >>> NFSD: Teach nfsd_mountpoint() auto mounts >>> fs: namei: Allow follow_down() to uncover auto mounts >>> NFS: nfs_encode_fh: Remove S_AUTOMOUNT check >>> >>> fs/namei.c | 6 +++--- >>> fs/nfs/export.c | 2 +- >>> fs/nfsd/vfs.c | 8 ++++++-- >>> include/linux/namei.h | 2 +- >>> 4 files changed, 11 insertions(+), 7 deletions(-) >>> >>> -- >>> 2.26.2 >>> >> >> This series is a bit late for inclusion in v6.2. The next opportunity >> will be v6.3 in a couple of months. I prefer to have a "final" version >> of patches by -rc5. >> >> I'm waiting for review comments on v2 of this series. > > Ok! Do you want me to resend the series in any case by v6.2-rc5 or only > if new comments arise? If v2 garners no new comments, then send a reminder with a URL to this thread on lore.kernel.org. I will pull the series from there. -- Chuck Lever
On Wed, 2022-12-07 at 09:43 +0100, Richard Weinberger wrote: > Currently when re-exporting a NFS share the NFS cross mount feature does > not work [0]. > This patch series outlines an approach to address the problem. > > Crossing mounts does not work for two reasons: > > 1. As soon the NFS client (on the re-exporting server) sees a different > filesystem id, it installs an automount. That way the other filesystem > will be mounted automatically when someone enters the directory. > But the cross mount logic of KNFS does not know about automount. > This patch series addresses the problem and teach both KNFSD > and the exportfs logic of NFS to deal with automount. > > 2. When KNFSD detects crossing of a mount point, it asks rpc.mountd to install > a new export for the target mount point. Beside of authentication rpc.mountd > also has to find a filesystem id for the new export. Is the to be exported > filesystem a NFS share, rpc.mountd cannot derive a filesystem id from it and > refuses to export. In the logs you'll see errors such as: > > mountd: Cannot export /srv/nfs/vol0, possibly unsupported filesystem or fsid= required > > To deal with that I've changed rpc.mountd to use generate and store fsids [1]. > Since the kernel side of my changes did change for a long time I decided to > try upstreaming it first. > A 3rd iteration of my rpc.mountd will happen soon. > > [0] https://marc.info/?l=linux-nfs&m=161653016627277&w=2 > [1] https://lore.kernel.org/linux-nfs/20220217131531.2890-1-richard@nod.at/ > > Changes since v1: > https://lore.kernel.org/linux-nfs/20221117191151.14262-1-richard@nod.at/ > > - Use LOOKUP_AUTOMOUNT only when NFSEXP_CROSSMOUNT is set (Jeff Layton) > > Richard Weinberger (3): > NFSD: Teach nfsd_mountpoint() auto mounts > fs: namei: Allow follow_down() to uncover auto mounts > NFS: nfs_encode_fh: Remove S_AUTOMOUNT check > > fs/namei.c | 6 +++--- > fs/nfs/export.c | 2 +- > fs/nfsd/vfs.c | 8 ++++++-- > include/linux/namei.h | 2 +- > 4 files changed, 11 insertions(+), 7 deletions(-) > This set looks reasonable to me. Reviewed-by: Jeff Layton <jlayton@kernel.org>
On 13/12/22 01:06, Jeff Layton wrote: > On Wed, 2022-12-07 at 09:43 +0100, Richard Weinberger wrote: >> Currently when re-exporting a NFS share the NFS cross mount feature does >> not work [0]. >> This patch series outlines an approach to address the problem. >> >> Crossing mounts does not work for two reasons: >> >> 1. As soon the NFS client (on the re-exporting server) sees a different >> filesystem id, it installs an automount. That way the other filesystem >> will be mounted automatically when someone enters the directory. >> But the cross mount logic of KNFS does not know about automount. >> This patch series addresses the problem and teach both KNFSD >> and the exportfs logic of NFS to deal with automount. >> >> 2. When KNFSD detects crossing of a mount point, it asks rpc.mountd to install >> a new export for the target mount point. Beside of authentication rpc.mountd >> also has to find a filesystem id for the new export. Is the to be exported >> filesystem a NFS share, rpc.mountd cannot derive a filesystem id from it and >> refuses to export. In the logs you'll see errors such as: >> >> mountd: Cannot export /srv/nfs/vol0, possibly unsupported filesystem or fsid= required >> >> To deal with that I've changed rpc.mountd to use generate and store fsids [1]. >> Since the kernel side of my changes did change for a long time I decided to >> try upstreaming it first. >> A 3rd iteration of my rpc.mountd will happen soon. >> >> [0] https://marc.info/?l=linux-nfs&m=161653016627277&w=2 >> [1] https://lore.kernel.org/linux-nfs/20220217131531.2890-1-richard@nod.at/ >> >> Changes since v1: >> https://lore.kernel.org/linux-nfs/20221117191151.14262-1-richard@nod.at/ >> >> - Use LOOKUP_AUTOMOUNT only when NFSEXP_CROSSMOUNT is set (Jeff Layton) >> >> Richard Weinberger (3): >> NFSD: Teach nfsd_mountpoint() auto mounts >> fs: namei: Allow follow_down() to uncover auto mounts >> NFS: nfs_encode_fh: Remove S_AUTOMOUNT check >> >> fs/namei.c | 6 +++--- >> fs/nfs/export.c | 2 +- >> fs/nfsd/vfs.c | 8 ++++++-- >> include/linux/namei.h | 2 +- >> 4 files changed, 11 insertions(+), 7 deletions(-) >> > This set looks reasonable to me. > > Reviewed-by: Jeff Layton <jlayton@kernel.org> Right, looks ok to me too, at least from the POV of that follow_down() change. Reviewed-by: Ian Kent <raven@themaw.net> Ian