Kernel update 3.5.7 -> 3.6.3 breaks NFS4

Commit Message

J. Bruce Fields Nov. 14, 2012, 4:08 p.m. UTC

On Wed, Nov 14, 2012 at 11:07:13AM -0500, J. Bruce Fields wrote:
> On Tue, Nov 13, 2012 at 07:58:15PM -0500, J. Bruce Fields wrote:
> > On Tue, Nov 13, 2012 at 05:40:05PM -0500, J. Bruce Fields wrote:
> > > On Mon, Nov 12, 2012 at 10:17:17AM +0100, Sven Geggus wrote:
> > > > J. Bruce Fields schrieb am Samstag, den 10. November um 00:24 Uhr:
> > > > 
> > > > OK, back at work and here is what I get:
> > > > 
> > > > > Restart the server, start strace, then try the mount, let it hang a few
> > > > > seconds just to make sure you got anything interesting, then kill strace
> > > > > and send the output.
> > > > 
> > > > OK, back at work and here is what I get...
> > > > 
> > > > read(3, "nfsd 10.1.7.30\n", 2048)       = 15
> > > > close(15)                               = 0
> > > > open("/var/lib/nfs/etab", O_RDONLY)     = 15
> > > > close(15)                               = 0
> > > > close(15)                               = 0
> > > > write(3, "nfsd 10.1.7.30 1352710828 * \n", 29) = 29
> > > > read(4, "4294967295\n", 2048)           = 11
> > > > close(16)                               = 0
> > > > close(15)                               = 0
> > > > read(15,
> > > > "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0",
> > > > 36) = 36
> > > > close(15)                               = 0
> > > > write(4, "4294967295 1352710828 0 \n", 25) = -1 EINVAL (Invalid argument)
> > > 
> > > I suspect that error's coming from
> > > net/sunrpc/svcauth_unix.c:unix_gid_parse().
> > > 
> > > > 4294967295 is UINT_MAX and this place is where it behaves differently on a good
> > > > kernel where the write call will succeed:
> > > > 
> > > > write(4, "4294967295 1352710828 0 \n", 25) = 25
> > > > 
> > > > Sven
> > > > 
> > > > P.S.: Your patched svcauth_gss.c will give me an "access denied by server"
> > > > while mounting instead of the infinite delay:
> > > >  ~/ # mount -t nfs4 -o sec=krb5 testsrv:/storage /mnt/
> > > > mount.nfs4: access denied by server while mounting testsrv:/storage
> > > 
> > > So, looks like the same get_int problem exists in several other places.
> > > Could you try the following instead of the previous patch?  I think I
> > > got them all this time....
> > 
> > Oh, cripes, but this isn't good enough--svcgssd actually passes down -1
> > id's.  Ugh--I'll take a closer look tomorrow.
> 
> Yeah, for backwards compatibility reasons we probably don't want to
> reject either -1 or 4294967295.
> 
> So I'm inclined to revert unless Eldad has a better idea.
> 
> --b.

Oops, sending the right thing this time.--b.

commit 8688bcb10bd006111b1b46c23a27081ea359e140
Author: J. Bruce Fields <[e-mail]>
Date:   Wed Nov 14 10:48:05 2012 -0500

    svcrpc: Revert "sunrpc/cache.h: replace simple_strtoul"
    
    Commit bbf43dc888833ac0539e437dbaeb28bfd4fbab9f "sunrpc/cache.h: replace
    simple_strtoul" introduced new range-checking which could cause get_int
    to fail on unsigned integers to large to be represented as an int.
    
    We could parse them as unsigned instead--but it turns out svcgssd is
    actually passing down "-1" in some cases.  Which is perhaps stupid, but
    there's nothing we can do about it now.
    
    So just revert back to the previous "sloppy" behavior that accepts
    either representation.
    
    Signed-off-by: J. Bruce Fields <[e-mail]>

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Sven Geggus Nov. 15, 2012, 4:58 p.m. UTC | #1

J. Bruce Fields schrieb am Mittwoch, den 14. November um 17:08 Uhr:

> commit 8688bcb10bd006111b1b46c23a27081ea359e140
> Author: J. Bruce Fields <[e-mail]>
> Date:   Wed Nov 14 10:48:05 2012 -0500
> 
>     svcrpc: Revert "sunrpc/cache.h: replace simple_strtoul"
>     
>     Commit bbf43dc888833ac0539e437dbaeb28bfd4fbab9f "sunrpc/cache.h: replace
>     simple_strtoul" introduced new range-checking which could cause get_int
>     to fail on unsigned integers to large to be represented as an int.
>     
>     We could parse them as unsigned instead--but it turns out svcgssd is
>     actually passing down "-1" in some cases.  Which is perhaps stupid, but
>     there's nothing we can do about it now.
>     
>     So just revert back to the previous "sloppy" behavior that accepts
>     either representation.
>     
>     Signed-off-by: J. Bruce Fields <[e-mail]>
> 
> diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h
> index f792794..5dc9ee4 100644
> --- a/include/linux/sunrpc/cache.h
> +++ b/include/linux/sunrpc/cache.h
> @@ -217,6 +217,8 @@ extern int qword_get(char **bpp, char *dest, int bufsize);
>  static inline int get_int(char **bpp, int *anint)
>  {
>  	char buf[50];
> +	char *ep;
> +	int rv;
>  	int len = qword_get(bpp, buf, sizeof(buf));
>  
>  	if (len < 0)
> @@ -224,9 +226,11 @@ static inline int get_int(char **bpp, int *anint)
>  	if (len == 0)
>  		return -ENOENT;
>  
> -	if (kstrtoint(buf, 0, anint))
> +	rv = simple_strtol(buf, &ep, 0);
> +	if (*ep)
>  		return -EINVAL;
>  
> +	*anint = rv;
>  	return 0;
>  }

OK, so this can be marked as resolved (for now) on my todo list, right? Will
this go into 3.6.7 and of course 3.7?

Sven

J. Bruce Fields Nov. 16, 2012, 7:19 p.m. UTC | #2

On Thu, Nov 15, 2012 at 05:58:24PM +0100, Sven Geggus wrote:
> OK, so this can be marked as resolved (for now) on my todo list, right? Will
> this go into 3.6.7 and of course 3.7?

Yep, I'll pass this along by next week.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sven Geggus Dec. 12, 2012, 11:15 a.m. UTC | #3

J. Bruce Fields <[e-mail]> wrote:

>> OK, so this can be marked as resolved (for now) on my todo list, right? Will
>> this go into 3.6.7 and of course 3.7?
> 
> Yep, I'll pass this along by next week.

As 3.7 has been relased now:

It looks like the unreverted Version is still present in Linux 3.7.0 as well
as 3.6.10

While it is easy enough to use
"git revert bbf43dc888833ac0539e437dbaeb28bfd4fbab9f" I would rather be able
to use vanilla kernels again.

Regards

Sven

J. Bruce Fields Dec. 12, 2012, 6:57 p.m. UTC | #4

Please don't drop me off the cc: line.

On Wed, Dec 12, 2012 at 11:15:27AM +0000, Sven Geggus wrote:
> J. Bruce Fields <[e-mail]> wrote:
> 
> >> OK, so this can be marked as resolved (for now) on my todo list, right? Will
> >> this go into 3.6.7 and of course 3.7?
> > 
> > Yep, I'll pass this along by next week.
> 
> As 3.7 has been relased now:
> 
> It looks like the unreverted Version is still present in Linux 3.7.0 as well
> as 3.6.10
> 
> While it is easy enough to use
> "git revert bbf43dc888833ac0539e437dbaeb28bfd4fbab9f" I would rather be able
> to use vanilla kernels again.

Right, apologies, I ended up deciding to hold that for the merge window.
It's marked for stable so should make it into 3.7.x as well.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h
index f792794..5dc9ee4 100644
--- a/include/linux/sunrpc/cache.h
+++ b/include/linux/sunrpc/cache.h
@@ -217,6 +217,8 @@  extern int qword_get(char **bpp, char *dest, int bufsize);
 static inline int get_int(char **bpp, int *anint)
 {
 	char buf[50];
+	char *ep;
+	int rv;
 	int len = qword_get(bpp, buf, sizeof(buf));
 
 	if (len < 0)
@@ -224,9 +226,11 @@  static inline int get_int(char **bpp, int *anint)
 	if (len == 0)
 		return -ENOENT;
 
-	if (kstrtoint(buf, 0, anint))
+	rv = simple_strtol(buf, &ep, 0);
+	if (*ep)
 		return -EINVAL;
 
+	*anint = rv;
 	return 0;
 }