If the nfs_acl program is available, Solaris clients expect both
version 2 and version 3 to be available; RPC_PROG_MISMATCH leads to a
mount failure. Fake RPC_PROG_UNAVAIL when asked for nfs_acl version 2.
Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Olaf Kirch <[email protected]>
Index: linux-2.6.11-rc2/net/sunrpc/svc.c
===================================================================
--- linux-2.6.11-rc2.orig/net/sunrpc/svc.c
+++ linux-2.6.11-rc2/net/sunrpc/svc.c
@@ -458,6 +458,13 @@ err_bad_prog:
goto sendit;
err_bad_vers:
+ if (prog == NFSACL_PROGRAM && vers == 2) {
+ /* If the nfs_acl program is available, Solaris clients expect
+ both version 2 and version 3 to be available;
+ RPC_PROG_MISMATCH leads to a mount failure. Fake
+ RPC_PROG_UNAVAIL when asked for nfs_acl version 2. */
+ goto err_bad_prog;
+ }
#ifdef RPC_PARANOIA
printk("svc: unknown version (%d)\n", vers);
#endif
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH
lau den 22.01.2005 Klokka 21:34 (+0100) skreiv Andreas Gruenbacher:
> Solaris nfsacl workaround
NACK. No hacks.
Trond
--
Trond Myklebust <[email protected]>
On Tue, Feb 15, 2005 at 12:29:06PM -0500, Trond Myklebust wrote:
> lau den 22.01.2005 Klokka 21:34 (+0100) skreiv Andreas Gruenbacher:
> > Solaris nfsacl workaround
>
> NACK. No hacks.
That's the second time I see you refusing an interoperability patch
without bothering to say what would be acceptable. Do we need a fork
between knfsd-pure and knfsd-actually-works-in-the-real-world or what?
OG.
ty den 15.02.2005 Klokka 21:35 (+0100) skreiv Olivier Galibert:
> That's the second time I see you refusing an interoperability patch
> without bothering to say what would be acceptable. Do we need a fork
> between knfsd-pure and knfsd-actually-works-in-the-real-world or what?
You appear to be under the misguided impression that if a patch is
reviewed, and rejected, then somehow the responsibility for resolving
your problem (and cleaning up the code) falls to the reviewer.
I'm not aware of any such rule.
Feel free to apply as many hacks as you like to your own private fork,
but the mainline kernel has to be maintained by a community of people
most of which will not be aware, when debugging the ACL code, of the
little special cases peppered around the RPC server code in an entirely
different section of the kernel.
In this particular case, there are 100s of solutions that do not involve
putting NFSv3 ACL code in the generic RPC layer. If there really is a
generic need for RPC programs to override the RFC-specified error that
is returned to the client, then one obvious solution is to add a
callback that allows them to do so.
Even a flag called RPC_SVC_DO_NOT_EVER_RETURN_BAD_VERS would be easier
to maintain.
Trond
--
Trond Myklebust <[email protected]>
On Tue, Feb 15, 2005 at 05:43:24PM -0500, Trond Myklebust wrote:
> ty den 15.02.2005 Klokka 21:35 (+0100) skreiv Olivier Galibert:
> > That's the second time I see you refusing an interoperability patch
> > without bothering to say what would be acceptable. Do we need a fork
> > between knfsd-pure and knfsd-actually-works-in-the-real-world or what?
>
> You appear to be under the misguided impression that if a patch is
> reviewed, and rejected, then somehow the responsibility for resolving
> your problem (and cleaning up the code) falls to the reviewer.
>
> I'm not aware of any such rule.
Resolving the problem and/or cleaning the code, no. Telling what kind
of patch would be acceptable is your responsability, yes. That's
where the difference is between a reviewer and a naysayer.
OG.
on den 16.02.2005 Klokka 00:02 (+0100) skreiv Olivier Galibert:
> Resolving the problem and/or cleaning the code, no. Telling what kind
> of patch would be acceptable is your responsability, yes.
Read the patch, read the earlier patch [2/13] in which the same hack
appeared in the client code, and see my response. I'm sure Andreas knows
exactly what was meant by the comment and why.
Trond
--
Trond Myklebust <[email protected]>
On Tue, Feb 15, 2005 at 06:37:19PM -0500, Trond Myklebust wrote:
> on den 16.02.2005 Klokka 00:02 (+0100) skreiv Olivier Galibert:
>
> > Resolving the problem and/or cleaning the code, no. Telling what kind
> > of patch would be acceptable is your responsability, yes.
>
> Read the patch, read the earlier patch [2/13] in which the same hack
> appeared in the client code, and see my response. I'm sure Andreas knows
> exactly what was meant by the comment and why.
Ok. You have my apologies then.
OG.
On Tue, 2005-02-15 at 18:29, Trond Myklebust wrote:
> lau den 22.01.2005 Klokka 21:34 (+0100) skreiv Andreas Gruenbacher:
> > Solaris nfsacl workaround
>
> NACK. No hacks.
Well, I'm not in the position to fix Solaris. It would be possible to
implement NFSACL for NFSv2 (Solaris has it), but I doubt that we need
it. Your NACK probably means we'll have to carry it around as a vendor
patch.
Cheers,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX GMBH
on den 16.02.2005 Klokka 17:17 (+0100) skreiv Andreas Gruenbacher:
> On Tue, 2005-02-15 at 18:29, Trond Myklebust wrote:
> > lau den 22.01.2005 Klokka 21:34 (+0100) skreiv Andreas Gruenbacher:
> > > Solaris nfsacl workaround
> >
> > NACK. No hacks.
>
> Well, I'm not in the position to fix Solaris. It would be possible to
> implement NFSACL for NFSv2 (Solaris has it), but I doubt that we need
> it. Your NACK probably means we'll have to carry it around as a vendor
> patch.
See the thread between Olivier Galibert & I. There are ways of doing
this which do not involve putting nfsacl code in the generic sunrpc
layer.
Either a callback or a flag in the "struct svc_program" to override the
standard RPC server reply (instead of checking the ACL program number)
would be fine as far as I'm concerned. I can't speak for Neil's
preferences, though.
I am, however, surprised when you say that Solaris has problems with
this. The PROG_MISMATCH error does also tell the client the minimum and
maximum supported version, so if all is working well, then it recognize
that we support version 3 only. It seems wierd that they should then
choose to treat that as an mount failure.
Cheers,
Trond
--
Trond Myklebust <[email protected]>
On Wed, 2005-02-16 at 18:05, Trond Myklebust wrote:
> I am, however, surprised when you say that Solaris has problems with
> this. The PROG_MISMATCH error does also tell the client the minimum and
> maximum supported version, so if all is working well, then it recognize
> that we support version 3 only. It seems wierd that they should then
> choose to treat that as an mount failure.
Well, yes. It's a weird bug.
Cheers,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX GMBH