Hi!
while experimenting with various modifications in mountd to deal better with crossmounts
I noticed a problem in fs/nfsd/export.c svc_export_parse(), it always ignores the uuid
as provided by my mountd.
If CONFIG_NFSD_V4 is not enabled, both fsloc_parse() and secinfo_parse() are a no-op.
This causes the while loop to terminate prematurely because only the keywords "fsloc" or "secinfo"
got consumed, their parameters are still in the buffer and will trigger the break.
while ((len = qword_get(&mesg, buf, PAGE_SIZE)) > 0) {
if (strcmp(buf, "fsloc") == 0)
err = fsloc_parse(&mesg, buf, &exp.ex_fslocs);
else if (strcmp(buf, "uuid") == 0)
err = nfsd_uuid_parse(&mesg, buf, &exp.ex_uuid);
else if (strcmp(buf, "secinfo") == 0)
err = secinfo_parse(&mesg, buf, &exp);
else
/* quietly ignore unknown words and anything
* following. Newer user-space can try to set
* new values, then see what the result was.
*/
break;
if (err)
goto out4;
}
nfs-utils mountd always places fslock and secinfo before the uuid, no mather
whether I use NFSv4 or v3.
So I'm not sure where to address the problem. Should we fix mountd or
change both fsloc_parse() and secinfo_parse() to consume all their
data even in the !CONFIG_NFSD_V4 case?
Thanks,
//richard
On Thu, Jan 27, 2022 at 01:22:31PM +0100, Richard Weinberger wrote:
> Hi!
>
> while experimenting with various modifications in mountd to deal better with crossmounts
> I noticed a problem in fs/nfsd/export.c svc_export_parse(), it always ignores the uuid
> as provided by my mountd.
>
> If CONFIG_NFSD_V4 is not enabled, both fsloc_parse() and secinfo_parse() are a no-op.
Ugh, yeah, that's totally wrong. The secinfo applies to v3 too, and in
the fsloc case you still want to parse the stuff even if you're only
going to ignore it.
> So I'm not sure where to address the problem. Should we fix mountd or
> change both fsloc_parse() and secinfo_parse() to consume all their
> data even in the !CONFIG_NFSD_V4 case?
Yeah, the latter. So, maybe the remove the ifdefs.
(Should we remove CONFIG_NFSD_V4? I doubt v3-only kernels get much
testing.)
--b.
diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index 9421dae22737..9bdb5e102ba5 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -442,8 +442,6 @@ static int check_export(struct path *path, int *flags, unsigned char *uuid)
}
-#ifdef CONFIG_NFSD_V4
-
static int
fsloc_parse(char **mesg, char *buf, struct nfsd4_fs_locations *fsloc)
{
@@ -539,13 +537,6 @@ static int secinfo_parse(char **mesg, char *buf, struct svc_export *exp)
return 0;
}
-#else /* CONFIG_NFSD_V4 */
-static inline int
-fsloc_parse(char **mesg, char *buf, struct nfsd4_fs_locations *fsloc){return 0;}
-static inline int
-secinfo_parse(char **mesg, char *buf, struct svc_export *exp) { return 0; }
-#endif
-
static inline int
nfsd_uuid_parse(char **mesg, char *buf, unsigned char **puuid)
{
> On Jan 27, 2022, at 11:37 AM, J. Bruce Fields <[email protected]> wrote:
>
> (Should we remove CONFIG_NFSD_V4? I doubt v3-only kernels get much
> testing.)
I was just thinking that it might be time to consider removing
all the version specific CONFIG options... that would certainly
make it simpler to remove NFSv2 support when the time comes.
--
Chuck Lever