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
next prev 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