1. 04 Nov, 2012 1 commit
  2. 13 Apr, 2012 1 commit
  3. 01 Feb, 2012 1 commit
  4. 16 Dec, 2010 4 commits
    • Chuck Lever's avatar
      SUNRPC: New xdr_streams XDR decoder API · bf269551
      Chuck Lever authored
      Now that all client-side XDR decoder routines use xdr_streams, there
      should be no need to support the legacy calling sequence [rpc_rqst *,
      __be32 *, RPC res *] anywhere.  We can construct an xdr_stream in the
      generic RPC code, instead of in each decoder function.
      
      This is a refactoring change.  It should not cause different behavior.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      bf269551
    • Chuck Lever's avatar
      SUNRPC: New xdr_streams XDR encoder API · 9f06c719
      Chuck Lever authored
      Now that all client-side XDR encoder routines use xdr_streams, there
      should be no need to support the legacy calling sequence [rpc_rqst *,
      __be32 *, RPC arg *] anywhere.  We can construct an xdr_stream in the
      generic RPC code, instead of in each encoder function.
      
      Also, all the client-side encoder functions return 0 now, making a
      return value superfluous.  Take this opportunity to convert them to
      return void instead.
      
      This is a refactoring change.  It should not cause different behavior.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      9f06c719
    • Chuck Lever's avatar
      lockd: Introduce new-style XDR functions for NLMv4 · 3460f29a
      Chuck Lever authored
      We'd like to prevent local buffer overflows caused by malicious or
      broken servers.  New xdr_stream style decoders can do that.
      
      For efficiency, we also want to be able to pass xdr_streams from
      call_encode() to all XDR encoding functions, rather than building
      an xdr_stream in every XDR encoding function in the kernel.
      
      Same idea as the NLM v3 XDR overhaul.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      3460f29a
    • Chuck Lever's avatar
      lockd: Introduce new-style XDR functions for NLMv3 · 2b061f9e
      Chuck Lever authored
      We'd like to prevent local buffer overflows caused by malicious or
      broken servers.  New xdr_stream style decoders can do that.
      
      For efficiency, we also eventually want to be able to pass xdr_streams
      from call_encode() and call_decode() to all XDR encoding functions,
      rather than building an xdr_stream in every XDR encoding and decoding
      function in the kernel.
      
      To do all of this, rewrite the XDR encoding and decoding functions in
      fs/lockd/xdr.c to use xdr_streams.  This makes them more or less
      incompatible with server-side XDR helper functions, so break them out
      into a separate source file.
      
      Static helper functions are left without the "inline" directive.  This
      allows the compiler to choose automatically how to optimize these for
      size or speed.
      
      SHARE-related functionality doesn't seem to be used, as those
      functions are hiding behind a #define that isn't set anywhere that I
      can find.  And, they've been in there forever (at least as far back as
      the kernel's git history goes), yet remain unused.  Let's take the
      opportunity to bin them.  It should be easy enough for someone to
      introduce proper XDR functions if at some point SHARE-related NLM
      functionality is desired.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      2b061f9e