Re: [PATCH v2 0/5] sunrpc: sparse warning cleanups

[Jeff Layton <jeff.layton@primarydata.com>]

On Wed, 16 Jul 2014 06:52:17 -0400
Jeff Layton <jlayton@primarydata.com> wrote:

> v2:
> - reworked the gss_krb5_seal.c and gss_krb5_wrap.c patches to be less
>   ugly
> - squashed the setup_token patch into the gss_krb5_seal.c patch
> - dropped patch to make xdr_get_next_encode_buffer static since Trond
>   proposed the same fix
> 
> This fixes up all of the sparse warnings that I see when building
> net/sunrpc. The only real substantive change is the second patch which
> should fix the RCU handling for the gc_ctx field. That looks quite wrong
> right now, though it may be that the refcounting and lifecycle of the
> thing helps paper over it today.
> 
> There are still a few warnings that come from generic ipv6.h inlines.
> I'll send a separate patch to the netdev folks to address those.
> 
> Trond, if these look OK then they should probably go via your tree as it
> looks like you've already merged the gc_acceptor patches and the RCU
> fixes in patch #2 should apply on top of those.
> 
> Jeff Layton (5):
>   sunrpc: remove __rcu annotation from struct gss_cl_ctx->gc_gss_ctx
>   sunrpc: fix RCU handling of gc_ctx field
>   sunrpc: clean up sparse endianness warnings in gss_krb5_seal.c
>   sunrpc: clean up sparse endianness warnings in gss_krb5_wrap.c
>   sunrpc: remove "ec" argument from encrypt_v2 operation
> 
>  include/linux/sunrpc/auth_gss.h       |  2 +-
>  include/linux/sunrpc/gss_krb5.h       |  4 +--
>  net/sunrpc/auth_gss/auth_gss.c        | 52 +++++++++++++++++++++++------------
>  net/sunrpc/auth_gss/gss_krb5_crypto.c |  9 ++----
>  net/sunrpc/auth_gss/gss_krb5_seal.c   | 28 +++++++++++--------
>  net/sunrpc/auth_gss/gss_krb5_wrap.c   | 20 +++++++++-----
>  6 files changed, 70 insertions(+), 45 deletions(-)
> 

Trond, I noticed that you hadn't yet picked these patches up into your
tree. I'd like to get these in since they do make it easier to spot
real bugs with sparse. Are these better fed via your or Bruce's tree?

Thanks,
-- 
Jeff Layton <jlayton@primarydata.com>