1. 08 Feb, 2010 1 commit
    • J. Bruce Fields's avatar
      Revert "nfsd4: fix error return when pseudoroot missing" · 260c64d2
      J. Bruce Fields authored
      Commit f39bde24 fixed the error return from PUTROOTFH in the
      case where there is no pseudofilesystem.
      
      This is really a case we shouldn't hit on a correctly configured server:
      in the absence of a root filehandle, there's no point accepting version
      4 NFS rpc calls at all.
      
      But the shared responsibility between kernel and userspace here means
      the kernel on its own can't eliminate the possiblity of this happening.
      And we have indeed gotten this wrong in distro's, so new client-side
      mount code that attempts to negotiate v4 by default first has to work
      around this case.
      
      Therefore when commit f39bde24 arrived at roughly the same
      time as the new v4-default mount code, which explicitly checked only for
      the previous error, the result was previously fine mounts suddenly
      failing.
      
      We'll fix both sides for now: revert the error change, and make the
      client-side mount workaround more robust.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      260c64d2
  2. 06 Jan, 2010 2 commits
    • Xiaotian Feng's avatar
      sunrpc: fix peername failed on closed listener · b292cf9c
      Xiaotian Feng authored
      There're some warnings of "nfsd: peername failed (err 107)!"
      socket error -107 means Transport endpoint is not connected.
      This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
      when kernel_getpeername returns -107. This means socket might be CLOSED.
      
      And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]
      
              if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
              <snip>
                      newxpt = xprt->xpt_ops->xpo_accept(xprt);
              <snip>
      
      So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.
      
      Let's take a look at commit b0401d72, this commit has moved the close
      processing after do recvfrom method, but this commit also introduces this
      warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
      close it, not accpet then close.
      Signed-off-by: default avatarXiaotian Feng <dfeng@redhat.com>
      Cc: J. Bruce Fields <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      b292cf9c
    • Christoph Hellwig's avatar
      nfsd: make sure data is on disk before calling ->fsync · 7211a4e8
      Christoph Hellwig authored
      nfsd is not using vfs_fsync, so I missed it when changing the calling
      convention during the 2.6.32 window.  This patch fixes it to not only
      start the data writeout, but also wait for it to complete before calling
      into ->fsync.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      7211a4e8
  3. 20 Dec, 2009 1 commit
  4. 15 Dec, 2009 12 commits
  5. 14 Dec, 2009 14 commits
  6. 25 Nov, 2009 1 commit
    • J. Bruce Fields's avatar
      nfsd: simplify fh_verify access checks · 864f0f61
      J. Bruce Fields authored
      All nfsd security depends on the security checks in fh_verify, and
      especially on nfsd_setuser().
      
      It therefore bothers me that the nfsd_setuser call may be made from
      three different places, depending on whether the filehandle has already
      been mapped to a dentry, and on whether subtreechecking is in force.
      
      Instead, make an unconditional call in fh_verify(), so it's trivial to
      verify that the call always occurs.
      
      That leaves us with a redundant nfsd_setuser() call in the subtreecheck
      case--it needs the correct user set earlier in order to check execute
      permissions on the path to this filehandle--but I'm willing to accept
      that minor inefficiency in the subtreecheck case in return for more
      straightforward permission checking.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      864f0f61
  7. 23 Nov, 2009 2 commits
  8. 19 Nov, 2009 7 commits