1. 11 Jan, 2011 1 commit
  2. 17 Dec, 2010 1 commit
    • NeilBrown's avatar
      sunrpc: remove xpt_pool · 7c96aef7
      NeilBrown authored
      
      
      The xpt_pool field is only used for reporting BUGs.
      And it isn't used correctly.
      
      In particular, when it is cleared in svc_xprt_received before
      XPT_BUSY is cleared, there is no guarantee that either the
      compiler or the CPU might not re-order to two assignments, just
      setting xpt_pool to NULL after XPT_BUSY is cleared.
      
      If a different cpu were running svc_xprt_enqueue at this moment,
      it might see XPT_BUSY clear and then xpt_pool non-NULL, and
      so BUG.
      
      This could be fixed by calling
        smp_mb__before_clear_bit()
      before the clear_bit.  However as xpt_pool isn't really used,
      it seems safest to simply remove xpt_pool.
      
      Another alternate would be to change the clear_bit to
      clear_bit_unlock, and the test_and_set_bit to test_and_set_bit_lock.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      7c96aef7
  3. 02 Nov, 2010 1 commit
  4. 01 Oct, 2010 3 commits
  5. 27 Sep, 2010 1 commit
  6. 11 Sep, 2009 1 commit
  7. 28 Apr, 2009 2 commits
    • Chuck Lever's avatar
      NFSD: Prevent a buffer overflow in svc_xprt_names() · 335c54bd
      Chuck Lever authored
      
      
      The svc_xprt_names() function can overflow its buffer if it's so near
      the end of the passed in buffer that the "name too long" string still
      doesn't fit.  Of course, it could never tell if it was near the end
      of the passed in buffer, since its only caller passes in zero as the
      buffer length.
      
      Let's make this API a little safer.
      
      Change svc_xprt_names() so it *always* checks for a buffer overflow,
      and change its only caller to pass in the correct buffer length.
      
      If svc_xprt_names() does overflow its buffer, it now fails with an
      ENAMETOOLONG errno, instead of trying to write a message at the end
      of the buffer.  I don't like this much, but I can't figure out a clean
      way that's always safe to return some of the names, *and* an
      indication that the buffer was not long enough.
      
      The displayed error when doing a 'cat /proc/fs/nfsd/portlist' is
      "File name too long".
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      335c54bd
    • Chuck Lever's avatar
      SUNRPC: Fix error return value of svc_addr_len() · abc5c44d
      Chuck Lever authored
      
      
      The svc_addr_len() helper function returns -EAFNOSUPPORT if it doesn't
      recognize the address family of the passed-in socket address.  However,
      the return type of this function is size_t, which means -EAFNOSUPPORT
      is turned into a very large positive value in this case.
      
      The check in svc_udp_recvfrom() to see if the return value is less
      than zero therefore won't work at all.
      
      Additionally, handle_connect_req() passes this value directly to
      memset().  This could cause memset() to clobber a large chunk of memory
      if svc_addr_len() has returned an error.  Currently the address family
      of these addresses, however, is known to be supported long before
      handle_connect_req() is called, so this isn't a real risk.
      
      Change the error return value of svc_addr_len() to zero, which fits in
      the range of size_t, and is safer to pass to memset() directly.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      abc5c44d
  8. 28 Mar, 2009 3 commits
  9. 18 Mar, 2009 1 commit
  10. 31 Oct, 2008 1 commit
  11. 29 Oct, 2008 2 commits
  12. 01 Feb, 2008 23 commits