On Wed, 14 Nov 2012, 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: > > > > > > > > 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. I support that - please revert. I don't know my way around the code enough to suggest a good solution at this point. Cheers, Eldad -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
