Hey Neil,
It seems in nfs-utils-1.05 (actually it happen in 1.0.4)
the NFSEXP_CROSSMNT define was changed to 0x4000 and the
NFSEXP_NOHIDE define (which is not supported in 2.4) took
over the 0x0200 bit.. This breaks backwards compatibly with
1.0.3 and the 2.4 kernels...
So could please add this patch that simply switchs the bits
so NFSEXP_CROSSMNT stays the same and the new NFSEXP_NOHIDE define
gets the higher bit?
--- support/include/nfs/export.h.diff Mon Jul 14 18:14:01 2003
+++ support/include/nfs/export.h Thu Jul 31 11:58:05 2003
@@ -20,11 +20,11 @@
#define NFSEXP_UIDMAP 0x0040
#define NFSEXP_KERBEROS 0x0080 /* not available */
#define NFSEXP_SUNSECURE 0x0100
-#define NFSEXP_NOHIDE 0x0200
+#define NFSEXP_CROSSMNT 0x0200
#define NFSEXP_NOSUBTREECHECK 0x0400
#define NFSEXP_NOAUTHNLM 0x0800
#define NFSEXP_FSID 0x2000
-#define NFSEXP_CROSSMNT 0x4000
+#define NFSEXP_NOHIDE 0x4000
#define NFSEXP_NOACL 0x8000 /* reserved for possible ACL
related use */
#define NFSEXP_ALLFLAGS 0xFFFF
SteveD.
According to Steve Dickson:
> It seems in nfs-utils-1.05 (actually it happen in 1.0.4)
> the NFSEXP_CROSSMNT define was changed to 0x4000 ....
This looks like an actual kernel incompatibility 2.4 <-> 2.6, as
the 2.4 and 2.6 trees disagree about the value of NFSEXP_CROSSMNT.
> So could please add this patch that simply switchs the bits
> so NFSEXP_CROSSMNT stays the same and the new NFSEXP_NOHIDE define
> gets the higher bit?
And 2.6's include/linux/nfsd/export.h needs the same fix. This needs
to go in before the 2.6.0 release or nfs-utils is in deep kimchi.
--
Chip Salzenberg - a.k.a. - <[email protected]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Chip Salzenberg <[email protected]> wrote:
>
> According to Steve Dickson:
> > It seems in nfs-utils-1.05 (actually it happen in 1.0.4)
> > the NFSEXP_CROSSMNT define was changed to 0x4000 ....
>
> This looks like an actual kernel incompatibility 2.4 <-> 2.6, as
> the 2.4 and 2.6 trees disagree about the value of NFSEXP_CROSSMNT.
yup.
> > So could please add this patch that simply switchs the bits
> > so NFSEXP_CROSSMNT stays the same and the new NFSEXP_NOHIDE define
> > gets the higher bit?
>
> And 2.6's include/linux/nfsd/export.h needs the same fix. This needs
> to go in before the 2.6.0 release or nfs-utils is in deep kimchi.
Like this?
diff -puN include/linux/nfsd/export.h~nfs-flags-untangle include/linux/nfsd/export.h
--- 25/include/linux/nfsd/export.h~nfs-flags-untangle Thu Jul 31 15:04:25 2003
+++ 25-akpm/include/linux/nfsd/export.h Thu Jul 31 15:04:49 2003
@@ -35,12 +35,12 @@
#define NFSEXP_UIDMAP 0x0040
#define NFSEXP_KERBEROS 0x0080 /* not available */
#define NFSEXP_SUNSECURE 0x0100
-#define NFSEXP_NOHIDE 0x0200
+#define NFSEXP_CROSSMNT 0x0200
#define NFSEXP_NOSUBTREECHECK 0x0400
#define NFSEXP_NOAUTHNLM 0x0800 /* Don't authenticate NLM requests - just trust */
#define NFSEXP_MSNFS 0x1000 /* do silly things that MS clients expect */
#define NFSEXP_FSID 0x2000
-#define NFSEXP_CROSSMNT 0x4000
+#define NFSEXP_NOHIDE 0x4000
#define NFSEXP_ALLFLAGS 0x7FFF
_
--- linux-2.4/fs/nfsd/vfs.c.diff 2003-07-31 10:35:27.000000000 -0400
+++ linux-2.4/fs/nfsd/vfs.c 2003-08-01 08:32:06.000000000 -0400
@@ -82,7 +82,7 @@ static struct raparms * raparm_cache;
* N.B. After this call _both_ fhp and resfh need an fh_put
*
* If the lookup would cross a mountpoint, and the mounted filesystem
- * is exported to the client with NFSEXP_CROSSMNT, then the lookup is
+ * is exported to the client with NFSEXP_NOHIDE, then the lookup is
* accepted as it stands and the mounted directory is
* returned. Otherwise the covered directory is returned.
* NOTE: this mountpoint crossing is not supported properly by all
@@ -116,7 +116,7 @@ nfsd_lookup(struct svc_rqst *rqstp, stru
dentry = dget(dparent);
else if (dparent != exp->ex_dentry)
dentry = dget(dparent->d_parent);
- else if (!EX_CROSSMNT(exp))
+ else if (!EX_NOHIDE(exp))
dentry = dget(dparent); /* .. == . just like at / */
else {
/* checking mountpoint crossing is very different when stepping up */
--- linux-2.4/fs/nfsd/export.c.diff 2003-07-31 10:35:27.000000000 -0400
+++ linux-2.4/fs/nfsd/export.c 2003-08-01 08:27:27.000000000 -0400
@@ -640,7 +640,7 @@ struct flags {
{ NFSEXP_UIDMAP, {"uidmap", ""}},
{ NFSEXP_KERBEROS, { "kerberos", ""}},
{ NFSEXP_SUNSECURE, { "sunsecure", ""}},
- { NFSEXP_CROSSMNT, {"nohide", ""}},
+ { NFSEXP_NOHIDE, {"nohide", ""}},
{ NFSEXP_NOSUBTREECHECK, {"no_subtree_check", ""}},
{ NFSEXP_NOAUTHNLM, {"insecure_locks", ""}},
#ifdef MSNFS
--- linux-2.4/include/linux/nfsd/export.h.diff 2003-07-31 10:36:23.000000000 -0400
+++ linux-2.4/include/linux/nfsd/export.h 2003-08-01 08:31:15.000000000 -0400
@@ -35,7 +35,7 @@
#define NFSEXP_UIDMAP 0x0040
#define NFSEXP_KERBEROS 0x0080 /* not available */
#define NFSEXP_SUNSECURE 0x0100
-#define NFSEXP_CROSSMNT 0x0200
+#define NFSEXP_NOHIDE 0x0200
#define NFSEXP_NOSUBTREECHECK 0x0400
#define NFSEXP_NOAUTHNLM 0x0800 /* Don't authenticate NLM requests - just trust */
#define NFSEXP_MSNFS 0x1000 /* do silly things that MS clients expect */
@@ -80,7 +80,7 @@ struct svc_export {
#define EX_SECURE(exp) (!((exp)->ex_flags & NFSEXP_INSECURE_PORT))
#define EX_ISSYNC(exp) (!((exp)->ex_flags & NFSEXP_ASYNC))
#define EX_RDONLY(exp) ((exp)->ex_flags & NFSEXP_READONLY)
-#define EX_CROSSMNT(exp) ((exp)->ex_flags & NFSEXP_CROSSMNT)
+#define EX_NOHIDE(exp) ((exp)->ex_flags & NFSEXP_NOHIDE)
#define EX_SUNSECURE(exp) ((exp)->ex_flags & NFSEXP_SUNSECURE)
#define EX_WGATHER(exp) ((exp)->ex_flags & NFSEXP_GATHERED_WRITES)
According to Neil Brown:
> I don't know if there is any such code, but if there is I apoligize for
> breaking it and suggest that the best fix is to not use the header
> file it was using but it explicitly include the values for NFSEXP_* in
> that code.
The only really bad thing about the current situation is that the name
"NFSEXP_CROSSMNT" is poisoned by having had two historical
definitions. So it that name should be dropped, IMO, and replaced by
something textually different. "NFSEXP_XMOUNT", perhaps. Even
"NFSEXP_CROSSMNT2" would work. Just as long as code that said
"CROSSMNT" to mean "NOHIDE" wouldn't accidentally get CROSSMNT instead.
--
Chip Salzenberg - a.k.a. - <[email protected]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
On Friday August 1, [email protected] wrote:
> According to Neil Brown:
> > I don't know if there is any such code, but if there is I apoligize for
> > breaking it and suggest that the best fix is to not use the header
> > file it was using but it explicitly include the values for NFSEXP_* in
> > that code.
>
> The only really bad thing about the current situation is that the name
> "NFSEXP_CROSSMNT" is poisoned by having had two historical
> definitions. So it that name should be dropped, IMO, and replaced by
> something textually different. "NFSEXP_XMOUNT", perhaps. Even
> "NFSEXP_CROSSMNT2" would work. Just as long as code that said
> "CROSSMNT" to mean "NOHIDE" wouldn't accidentally get CROSSMNT instead.
If we were to change it, I would prefer NFSEXP_CROSSMOUNT.
I might send such a patch to Linus and update nfs-utils if/when it
gets included (or should 2.6 patches start going to Andrew now??)
NeilBrown
On Friday August 1, [email protected] wrote:
> I see your point... I guess I didn't realize that the "nohide" option
> (that the user
> sees) has been using the NFSEXP_CROSSMNT define this whole time....
>
> And I also agree with you if somebody is directly using the bits instead of
> the "nohide" ascii representation they are on there own since there is no
> real export API per say....
>
> But just to make the clean up complete, wouldn't the attached patch be
> needed in the 2.4 kernel if nfs-utils-1.0.5 was going to be used?
It wouldn't hurt, but it certainly isn't needed (as it doesn't
actually change any bit of compiled code).
I will put it on my list to send for 2.4.23-pre
NeilBrown