1. 10 5月, 2007 1 次提交
    • J
      RPC: add wrapper for svc_reserve to account for checksum · cd123012
      Jeff Layton 提交于
      When the kernel calls svc_reserve to downsize the expected size of an RPC
      reply, it fails to account for the possibility of a checksum at the end of
      the packet.  If a client mounts a NFSv2/3 with sec=krb5i/p, and does I/O
      then you'll generally see messages similar to this in the server's ring
      buffer:
      
      RPC request reserved 164 but used 208
      
      While I was never able to verify it, I suspect that this problem is also
      the root cause of some oopses I've seen under these conditions:
      
      https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227726
      
      This is probably also a problem for other sec= types and for NFSv4.  The
      large reserved size for NFSv4 compound packets seems to generally paper
      over the problem, however.
      
      This patch adds a wrapper for svc_reserve that accounts for the possibility
      of a checksum.  It also fixes up the appropriate callers of svc_reserve to
      call the wrapper.  For now, it just uses a hardcoded value that I
      determined via testing.  That value may need to be revised upward as things
      change, or we may want to eventually add a new auth_op that attempts to
      calculate this somehow.
      
      Unfortunately, there doesn't seem to be a good way to reliably determine
      the expected checksum length prior to actually calculating it, particularly
      with schemes like spkm3.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Acked-by: NNeil Brown <neilb@suse.de>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Acked-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd123012
  2. 01 5月, 2007 1 次提交
  3. 07 3月, 2007 2 次提交
  4. 21 2月, 2007 2 次提交
  5. 11 2月, 2007 1 次提交
  6. 10 2月, 2007 1 次提交
    • N
      [PATCH] knfsd: fix a race in closing NFSd connections · aaf68cfb
      NeilBrown 提交于
      If you lose this race, it can iput a socket inode twice and you get a BUG
      in fs/inode.c
      
      When I added the option for user-space to close a socket, I added some
      cruft to svc_delete_socket so that I could call that function when closing
      a socket per user-space request.
      
      This was the wrong thing to do.  I should have just set SK_CLOSE and let
      normal mechanisms do the work.
      
      Not only wrong, but buggy.  The locking is all wrong and it openned up a
      race where-by a socket could be closed twice.
      
      So this patch:
        Introduces svc_close_socket which sets SK_CLOSE then either leave
        the close up to a thread, or calls svc_delete_socket if it can
        get SK_BUSY.
      
        Adds a bias to sk_busy which is removed when SK_DEAD is set,
        This avoid races around shutting down the socket.
      
        Changes several 'spin_lock' to 'spin_lock_bh' where the _bh
        was missing.
      
      Bugzilla-url: http://bugzilla.kernel.org/show_bug.cgi?id=7916Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      aaf68cfb
  7. 04 2月, 2007 1 次提交
  8. 31 1月, 2007 1 次提交
  9. 27 1月, 2007 1 次提交
  10. 14 12月, 2006 1 次提交
  11. 17 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: Allow lockd to drop replies as appropriate · d343fce1
      NeilBrown 提交于
      It is possible for the ->fopen callback from lockd into nfsd to find that an
      answer cannot be given straight away (an upcall is needed) and so the request
      has to be 'dropped', to be retried later.  That error status is not currently
      propagated back.
      
      So:
        Change nlm_fopen to return nlm error codes (rather than a private
        protocol) and define a new nlm_drop_reply code.
        Cause nlm_drop_reply to cause the rpc request to get rpc_drop_reply
        when this error comes back.
        Cause svc_process to drop a request which returns a status of
        rpc_drop_reply.
      
      [akpm@osdl.org: fix warning storm]
      Cc: Marc Eshel <eshel@almaden.ibm.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d343fce1
  12. 06 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: tidy up up meaning of 'buffer size' in nfsd/sunrpc · c6b0a9f8
      NeilBrown 提交于
      There is some confusion about the meaning of 'bufsz' for a sunrpc server.
      In some cases it is the largest message that can be sent or received.  In
      other cases it is the largest 'payload' that can be included in a NFS
      message.
      
      In either case, it is not possible for both the request and the reply to be
      this large.  One of the request or reply may only be one page long, which
      fits nicely with NFS.
      
      So we remove 'bufsz' and replace it with two numbers: 'max_payload' and
      'max_mesg'.  Max_payload is the size that the server requests.  It is used
      by the server to check the max size allowed on a particular connection:
      depending on the protocol a lower limit might be used.
      
      max_mesg is the largest single message that can be sent or received.  It is
      calculated as the max_payload, rounded up to a multiple of PAGE_SIZE, and
      with PAGE_SIZE added to overhead.  Only one of the request and reply may be
      this size.  The other must be at most one page.
      
      Cc: Greg Banks <gnb@sgi.com>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c6b0a9f8
  13. 04 10月, 2006 4 次提交
  14. 02 10月, 2006 6 次提交
  15. 29 9月, 2006 2 次提交
  16. 22 7月, 2006 1 次提交
  17. 01 7月, 2006 2 次提交
  18. 12 1月, 2006 1 次提交
  19. 11 1月, 2006 1 次提交
  20. 10 1月, 2006 1 次提交
  21. 09 11月, 2005 1 次提交
  22. 07 11月, 2005 1 次提交
  23. 23 6月, 2005 2 次提交
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4