Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2479626ybe; Tue, 3 Sep 2019 13:34:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqwEtD3GYg1dCaP70lH605cmkXw7ur6MOrex7njSirU6Nf55npAwJf+z94t17sJ5RiKqIPcm X-Received: by 2002:a17:90a:d988:: with SMTP id d8mr1167072pjv.65.1567542897727; Tue, 03 Sep 2019 13:34:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567542897; cv=none; d=google.com; s=arc-20160816; b=jXBQBDAVpEcAiqsC7AqWqo0jSzOuc9tQs7p1L2QDyXZLbDxTX+3bNWNSJpdcsLHbAf QRTx+PNN9sss0/4PdSZqQO3uXMbfbsbz48wjQT5yjjQlRQZ4CCEUjsOdQizNT3d4gXRz tyJdgQf7cqpNIaxRiq+LBXEhd4ktUtG47JlNMMeAjugAJopZ7cVoqX/9jtzCJLYGXGhW SCCbWF8J7wUOzzyueV/Tu15i+KoYtgipVQpGLIx9DdCpc8zUXhddjtaXbDMLEXcTNk1g U+1y7Ief39mC8LnbLkU/ZlKuAAvWniwFOgFv39pQEmBzVHk7fOvm2s1DKlsdVyldGf27 GXWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=NJjkJEEWe0aa24iASl/3EZrtIy1D1CxV7qTmSe4Qw1o=; b=Mjw9/o5YEfY07t+1f/yIkU7EokglBcxj6WVwY7/QGnRJZK83qKXatOk4CqmDZvCqbZ qylsFgNbo1CEcbns9LWq+XBqWMT8tO3lLX+9PHJeahxUYdVJmFJ4nMbI3UHLeCGbq4AG asCvcMl/K7lsGXDHc05KRhZC241gWBrXExWREIOTZLpH5nUwMP5F+IeFfcoegbtPTrBt E/aV2sW504XgPcrpmwihVy+gZKUj0xEcbU6yj36bLTIwH3m5jzZ1/As5LK+sW0rE+Z1k 8BOw+g8RZ9ltE/UYZJZcvvTVKCC+Mv07kDqr+vZ3ak+cB82UC/5E2ggGWPU7xHz03Uob HHSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 23si18468741pfn.236.2019.09.03.13.34.42; Tue, 03 Sep 2019 13:34:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727257AbfICUcS (ORCPT + 99 others); Tue, 3 Sep 2019 16:32:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727002AbfICUcR (ORCPT ); Tue, 3 Sep 2019 16:32:17 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2510F10C6973; Tue, 3 Sep 2019 20:32:17 +0000 (UTC) Received: from coeurl.usersys.redhat.com (ovpn-121-35.rdu2.redhat.com [10.10.121.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id F154860BFB; Tue, 3 Sep 2019 20:32:16 +0000 (UTC) Received: by coeurl.usersys.redhat.com (Postfix, from userid 1000) id B815D20D31; Tue, 3 Sep 2019 16:32:15 -0400 (EDT) From: Scott Mayhew To: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com Cc: dhowells@redhat.com, viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 14/26] nfs_clone_sb_security(): simplify the check for server bogosity Date: Tue, 3 Sep 2019 16:32:03 -0400 Message-Id: <20190903203215.9157-15-smayhew@redhat.com> In-Reply-To: <20190903203215.9157-1-smayhew@redhat.com> References: <20190903203215.9157-1-smayhew@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.65]); Tue, 03 Sep 2019 20:32:17 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Al Viro We used to check ->i_op for being nfs_dir_inode_operations. With separate inode_operations for v3 and v4 that became bogus, but rather than going for protocol-dependent comparison we could've just checked ->i_fop instead; _that_ is the same for all protocol versions. Reviewed-by: David Howells Signed-off-by: Al Viro --- fs/nfs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 89751ce21110..6f4983fc3937 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2569,7 +2569,7 @@ int nfs_clone_sb_security(struct super_block *s, struct dentry *mntroot, unsigned long kflags = 0, kflags_out = 0; /* clone any lsm security options from the parent to the new sb */ - if (d_inode(mntroot)->i_op != NFS_SB(s)->nfs_client->rpc_ops->dir_inode_ops) + if (d_inode(mntroot)->i_fop != &nfs_dir_operations) return -ESTALE; if (NFS_SB(s)->caps & NFS_CAP_SECURITY_LABEL) -- 2.17.2