Linux NFS development
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Scott Mayhew <smayhew@redhat.com>,
	chuck.lever@oracle.com, jlayton@kernel.org
Cc: oe-kbuild-all@lists.linux.dev, neil@brown.name,
	okorniev@redhat.com, Dai.Ngo@oracle.com, tom@talpey.com,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfsd: decouple the xprtsec policy check from check_nfsd_access()
Date: Fri, 1 Aug 2025 18:23:14 +0800	[thread overview]
Message-ID: <202508011835.YXIfu0oy-lkp@intel.com> (raw)
In-Reply-To: <20250731211441.1908508-1-smayhew@redhat.com>

Hi Scott,

kernel test robot noticed the following build warnings:

[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on linus/master v6.16 next-20250801]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Scott-Mayhew/nfsd-decouple-the-xprtsec-policy-check-from-check_nfsd_access/20250801-051621
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.all
patch link:    https://lore.kernel.org/r/20250731211441.1908508-1-smayhew%40redhat.com
patch subject: [PATCH] nfsd: decouple the xprtsec policy check from check_nfsd_access()
config: i386-buildonly-randconfig-003-20250801 (https://download.01.org/0day-ci/archive/20250801/202508011835.YXIfu0oy-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250801/202508011835.YXIfu0oy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508011835.YXIfu0oy-lkp@intel.com/

All warnings (new ones prefixed by >>):

   fs/nfsd/export.c: In function 'exp_rootfh':
   fs/nfsd/export.c:1029:34: warning: variable 'inode' set but not used [-Wunused-but-set-variable]
    1029 |         struct inode            *inode;
         |                                  ^~~~~
   fs/nfsd/export.c: In function 'check_nfsd_access':
>> fs/nfsd/export.c:1153:26: warning: variable 'xprt' set but not used [-Wunused-but-set-variable]
    1153 |         struct svc_xprt *xprt;
         |                          ^~~~


vim +/xprt +1153 fs/nfsd/export.c

  1138	
  1139	/**
  1140	 * check_nfsd_access - check if access to export is allowed.
  1141	 * @exp: svc_export that is being accessed.
  1142	 * @rqstp: svc_rqst attempting to access @exp (will be NULL for LOCALIO).
  1143	 * @may_bypass_gss: reduce strictness of authorization check
  1144	 *
  1145	 * Return values:
  1146	 *   %nfs_ok if access is granted, or
  1147	 *   %nfserr_wrongsec if access is denied
  1148	 */
  1149	__be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
  1150				 bool may_bypass_gss)
  1151	{
  1152		struct exp_flavor_info *f, *end = exp->ex_flavors + exp->ex_nflavors;
> 1153		struct svc_xprt *xprt;
  1154	
  1155		/*
  1156		 * If rqstp is NULL, this is a LOCALIO request which will only
  1157		 * ever use a filehandle/credential pair for which access has
  1158		 * been affirmed (by ACCESS or OPEN NFS requests) over the
  1159		 * wire. So there is no need for further checks here.
  1160		 */
  1161		if (!rqstp)
  1162			return nfs_ok;
  1163	
  1164		xprt = rqstp->rq_xprt;
  1165	
  1166		/* legacy gss-only clients are always OK: */
  1167		if (exp->ex_client == rqstp->rq_gssclient)
  1168			return nfs_ok;
  1169		/* ip-address based client; check sec= export option: */
  1170		for (f = exp->ex_flavors; f < end; f++) {
  1171			if (f->pseudoflavor == rqstp->rq_cred.cr_flavor)
  1172				return nfs_ok;
  1173		}
  1174		/* defaults in absence of sec= options: */
  1175		if (exp->ex_nflavors == 0) {
  1176			if (rqstp->rq_cred.cr_flavor == RPC_AUTH_NULL ||
  1177			    rqstp->rq_cred.cr_flavor == RPC_AUTH_UNIX)
  1178				return nfs_ok;
  1179		}
  1180	
  1181		/* If the compound op contains a spo_must_allowed op,
  1182		 * it will be sent with integrity/protection which
  1183		 * will have to be expressly allowed on mounts that
  1184		 * don't support it
  1185		 */
  1186	
  1187		if (nfsd4_spo_must_allow(rqstp))
  1188			return nfs_ok;
  1189	
  1190		/* Some calls may be processed without authentication
  1191		 * on GSS exports. For example NFS2/3 calls on root
  1192		 * directory, see section 2.3.2 of rfc 2623.
  1193		 * For "may_bypass_gss" check that export has really
  1194		 * enabled some flavor with authentication (GSS or any
  1195		 * other) and also check that the used auth flavor is
  1196		 * without authentication (none or sys).
  1197		 */
  1198		if (may_bypass_gss && (
  1199		     rqstp->rq_cred.cr_flavor == RPC_AUTH_NULL ||
  1200		     rqstp->rq_cred.cr_flavor == RPC_AUTH_UNIX)) {
  1201			for (f = exp->ex_flavors; f < end; f++) {
  1202				if (f->pseudoflavor >= RPC_AUTH_DES)
  1203					return 0;
  1204			}
  1205		}
  1206	
  1207		return nfserr_wrongsec;
  1208	}
  1209	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2025-08-01 10:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31 21:14 [PATCH] nfsd: decouple the xprtsec policy check from check_nfsd_access() Scott Mayhew
2025-07-31 21:49 ` Scott Mayhew
2025-08-01  1:53 ` NeilBrown
2025-08-01 10:23 ` kernel test robot [this message]
2025-08-01 13:00 ` Jeff Layton
2025-08-01 13:24 ` Chuck Lever
2025-08-05 14:32   ` Scott Mayhew
2025-08-05 14:36     ` Chuck Lever
2025-08-05 14:51       ` Scott Mayhew

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202508011835.YXIfu0oy-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=Dai.Ngo@oracle.com \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=okorniev@redhat.com \
    --cc=smayhew@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox