Hi Malahal, Sure, we'll track it down. The most likely situation is use of segmented i/O in any case where, currently, due to our use of GSSAPI's gss_wrap and gss_getmic APIs, we can't tolerate it. Until we can support newer APIs (such as the one introduced in MIT kerberos 12) with vector support, we need to substitute contiguous output buffers whenever RPCSEC_GSS is in use.
Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ----- Original Message ----- > From: "Malahal Naineni" <mala...@us.ibm.com> > To: nfs-ganesha-devel@lists.sourceforge.net > Cc: "william allen simpson" <william.allen.simp...@gmail.com>, > mbenja...@redhat.com > Sent: Wednesday, October 7, 2015 8:50:17 PM > Subject: V2.3-dev-10 broke kerberos mounts, regression! > > Hi All, > > The latest ganesha2.3 doesn't work with kerberos mounts. It > appears to work with krb5 mounts but definitely fails with krb5i or > krb5p. I primarily tested with krb5p mounts, and git bisect pointed to > ganesha commit: 2de276416a5d2034fcd765434ed51794d622e916 > > That is just a submodule commit, so bisecting libntirpc pointed to this > commit: 378832326fea58945c88963cef7ef3fe8500fd47 > > I don't see much there but some new flags were introduced in that commit > related to gss. > > Appreciate if Matt or Bill can help figure this out. I am not familiar > with this area at all. The failure is very easy to recreate, the mount > itself fails. tcpdump shows we are sending something but the client > fails to decode the response. This results in mount() syscall failing > with EIO at the client. > > Regards, Malahal. > > ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
