From patchwork Tue Nov 17 11:52:48 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 7636431 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 2BEE89F1D3 for ; Tue, 17 Nov 2015 11:54:44 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4B759204E2 for ; Tue, 17 Nov 2015 11:54:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3B0C620501 for ; Tue, 17 Nov 2015 11:54:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753702AbbKQLyi (ORCPT ); Tue, 17 Nov 2015 06:54:38 -0500 Received: from mail-qg0-f46.google.com ([209.85.192.46]:33239 "EHLO mail-qg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753317AbbKQLxp (ORCPT ); Tue, 17 Nov 2015 06:53:45 -0500 Received: by qgea14 with SMTP id a14so3420205qge.0 for ; Tue, 17 Nov 2015 03:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poochiereds_net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=35FqEJopo4BdA0QMHAnjtbC3Ls8dFdqUSypsFP3ndyk=; b=JLUM8LJ9C1rNYbW9B0FmtnyzsD2jrZEdMpgWSUS12YDDXZHO/HYcTsCETXlqH7CChd 9tRqYxweBKngTOJcErw6TTyuocqEk01IAe3o4H51r6adH+aJFsyPqj85GQ9Vh0HmPlpI YhEj1GN7pxnlotBHMw/wGeo6PjFZmJ6xYwj4ifWa+lQ6iCY2v3YOp0z3vYRb2zdXG/fj Ek1b5NB4EbURaoLboYrz9m41dt0eaWkKguIEYC+J/v7SZw0NSRd1ZTifoAXlKLzpPcs/ ek0G6ZHxDP6PAZgoBm4pA0g+nsES7D523tmVHJUSBq8uxgTckodmRL/ObTr+i79nQmfl 2gWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=35FqEJopo4BdA0QMHAnjtbC3Ls8dFdqUSypsFP3ndyk=; b=hraQzDf7c1K0ut2lWNqIKdm/pjBt60PceM4COHnDF41KLhSrKyg34/M4l+hkX1vsjH d02FE+WOFinK5aaeCNpW50Du2UXZ9QTIk4PH1CuNLzVt3YY3OwY0c1qqmEbj2o8u3rft CIvC7+jfBzEat7eCFhqZACwdJcdiqT1P1Bm5odvwNfNk/XTM+v7c+LNyMKDmvnRAAQDX RU6kQFvyHAMMQBO5n0bLDgPPcJtSis48ZjkSHZtlfPyio07EKdgKe0/YB+1vfzYcjU8T S4jePBawYDDl0+mNDxJwD0He+b1r8pp0uP+NsqpYqC90zWd/vznzj3J0Typccvvthpqp 3Kdg== X-Gm-Message-State: ALoCoQnJQjts7oCPMXnYpkCAHweVksfqHC+IfHUPaLNv+lXBUzB4JNADv1/ZZzadbpfqUoJKuyiX X-Received: by 10.140.19.13 with SMTP id 13mr40297425qgg.97.1447761224606; Tue, 17 Nov 2015 03:53:44 -0800 (PST) Received: from tlielax.poochiereds.net ([2606:a000:1125:4075::d5a]) by smtp.googlemail.com with ESMTPSA id w10sm1583910qhc.16.2015.11.17.03.53.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Nov 2015 03:53:44 -0800 (PST) From: Jeff Layton X-Google-Original-From: Jeff Layton To: bfields@fieldses.org, trond.myklebust@primarydata.com Cc: linux-nfs@vger.kernel.org, Eric Paris , Alexander Viro , linux-fsdevel@vger.kernel.org Subject: [PATCH v1 26/38] nfsd: return EREMOTE if we find an S_AUTOMOUNT inode Date: Tue, 17 Nov 2015 06:52:48 -0500 Message-Id: <1447761180-4250-27-git-send-email-jeff.layton@primarydata.com> X-Mailer: git-send-email 2.4.3 In-Reply-To: <1447761180-4250-1-git-send-email-jeff.layton@primarydata.com> References: <1447761180-4250-1-git-send-email-jeff.layton@primarydata.com> Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Our interest with the NFS reexporting code is primarily to reexport NFSv4 filesystems, but there is no way to get the fsid that is associated with an inode. So, we must require that any reexported NFSv4 filesystem have an explicit fsid= value assigned to it. That value must also be persistent across reboots or we'll see a lot of ESTALE errors. Because of this requirement, we can't really deal with transparent automounting (and implicit exporting) of NFSv4 filesystems after a mountpoint traversal. Don't allow knfsd to traverse S_AUTOMOUNT inodes. If we find one in a LOOKUP then we simply return NFS3ERR_REMOTE. In the case of READDIRPLUS, we opt not to send any attributes for the inode, so the follow on stat() call (if any) can figure out that it's remote. Signed-off-by: Jeff Layton --- fs/nfsd/nfs3xdr.c | 2 ++ fs/nfsd/vfs.c | 8 ++++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/nfsd/nfs3xdr.c b/fs/nfsd/nfs3xdr.c index 6420e28a4d2f..8c8c89bc752b 100644 --- a/fs/nfsd/nfs3xdr.c +++ b/fs/nfsd/nfs3xdr.c @@ -833,6 +833,8 @@ compose_entry_fh(struct nfsd3_readdirres *cd, struct svc_fh *fhp, goto out; if (d_really_is_negative(dchild)) goto out; + if (IS_AUTOMOUNT(dchild->d_inode)) + goto out; if (dchild->d_inode->i_ino != ino) goto out; rv = fh_compose(fhp, exp, dchild, &cd->fh); diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index 0b5072632ae5..d3fac79c4eaa 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -244,8 +244,12 @@ nfsd_lookup(struct svc_rqst *rqstp, struct svc_fh *fhp, const char *name, * dentry may be negative, it may need to be updated. */ err = fh_compose(resfh, exp, dentry, fhp); - if (!err && d_really_is_negative(dentry)) - err = nfserr_noent; + if (!err) { + if (d_really_is_negative(dentry)) + err = nfserr_noent; + else if (IS_AUTOMOUNT(dentry->d_inode)) + err = nfserr_remote; + } out: dput(dentry); exp_put(exp);