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: 7636441 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id F0E54BF90C 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 26629204EC for ; Tue, 17 Nov 2015 11:54:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4D1B3204EA for ; Tue, 17 Nov 2015 11:54:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753705AbbKQLyk (ORCPT ); Tue, 17 Nov 2015 06:54:40 -0500 Received: from mail-qg0-f46.google.com ([209.85.192.46]:36199 "EHLO mail-qg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753534AbbKQLxp (ORCPT ); Tue, 17 Nov 2015 06:53:45 -0500 Received: by qgad10 with SMTP id d10so3412590qga.3 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=M/hbwt6XXhHX4n2tHzbMN/m64kXlER17mUw59QosValb6HnHg0agw/GQe/YyfF1Fzt AyVlxD9ZvXmi6dofUBYHWVByG1BVQzZzmXabSrq6v66srIrRtCNvX74lO0drjUo8JXq7 R5QdGTdzSfroC83cXlQ8YdnuxLnymafAEuSXcdKoU9ypKsvgw32O8ND/09sVKwbO3ZKo NGzDvAkPTW5xCp+oZ9WzvNIwSKoJXaluy8WXUN5dWfqtSrKWyeT6pNt3H529nc5xaUmD OMsnwB7bp/Uml/x+xuwtMDGb9Ac+820ZXpFHmpK469nzHEUlwMI3d4g+UoVOcagDSk8c 67Ng== X-Gm-Message-State: ALoCoQmFhFz/f6ySz2Y8mYBCeuYuPe1H/Ivt3n9mZsw66FACsyK3CkSaFecAHAFeIa2odUbC/ddt 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@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=unavailable 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);