On Tue, 15 Jul 2014 10:04:42 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Sun, Jul 13, 2014 at 09:57:43PM -0400, Jeff Layton wrote: > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxxxxxxx> > > --- > > net/sunrpc/auth_gss/gss_krb5_wrap.c | 10 +++++----- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/net/sunrpc/auth_gss/gss_krb5_wrap.c b/net/sunrpc/auth_gss/gss_krb5_wrap.c > > index 42560e55d978..c5cc0270a334 100644 > > --- a/net/sunrpc/auth_gss/gss_krb5_wrap.c > > +++ b/net/sunrpc/auth_gss/gss_krb5_wrap.c > > @@ -201,9 +201,9 @@ gss_wrap_kerberos_v1(struct krb5_ctx *kctx, int offset, > > > > msg_start = ptr + GSS_KRB5_TOK_HDR_LEN + kctx->gk5e->cksumlength; > > > > + *(__be16 *)(ptr + 2) = (__force __be16)cpu_to_le16(kctx->gk5e->signalg); > > This looks silly. This should be: > > *(__le16 *)(ptr + 2) = cpu_to_le16(kctx->gk5e->signalg); > > Maybe with a comment somewhere explaining why we're doing little endian > encoding here if it's not obvious from the surrounding code. > The spec doesn't really define these as little-endian values, it's just an opaque series of bytes that the kernel implementation happens to handle as little-endian (see RFC 1964, section 1.2.1). Maybe I should reverse the bytes and we can just make that cpu_to_be16 instead? So the code is correct, AFAICT -- it's just odd... -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
