1. 30 Jul, 2010 1 commit
  2. 07 Jul, 2010 1 commit
    • Chuck Lever's avatar
      NFSD: Fill in WCC data for REMOVE, RMDIR, MKNOD, and MKDIR · 43a9aa64
      Chuck Lever authored
      
      Some well-known NFSv3 clients drop their directory entry caches when
      they receive replies with no WCC data.  Without this data, they
      employ extra READ, LOOKUP, and GETATTR requests to ensure their
      directory entry caches are up to date, causing performance to suffer
      needlessly.
      
      In order to return WCC data, our server has to have both the pre-op
      and the post-op attribute data on hand when a reply is XDR encoded.
      The pre-op data is filled in when the incoming fh is locked, and the
      post-op data is filled in when the fh is unlocked.
      
      Unfortunately, for REMOVE, RMDIR, MKNOD, and MKDIR, the directory fh
      is not unlocked until well after the reply has been XDR encoded.  This
      means that encode_wcc_data() does not have wcc_data for the parent
      directory, so none is returned to the client after these operations
      complete.
      
      By unlocking the parent directory fh immediately after the internal
      operations for each NFS procedure is complete, the post-op data is
      filled in before XDR encoding starts, so it can be returned to the
      client properly.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      43a9aa64
  3. 15 Dec, 2009 1 commit
  4. 14 Dec, 2009 2 commits
  5. 13 Nov, 2009 1 commit
  6. 15 Jun, 2009 1 commit
  7. 18 Mar, 2009 2 commits
    • David Shaw's avatar
      Short write in nfsd becomes a full write to the client · 31dec253
      David Shaw authored
      
      If a filesystem being written to via NFS returns a short write count
      (as opposed to an error) to nfsd, nfsd treats that as a success for
      the entire write, rather than the short count that actually succeeded.
      
      For example, given a 8192 byte write, if the underlying filesystem
      only writes 4096 bytes, nfsd will ack back to the nfs client that all
      8192 bytes were written.  The nfs client does have retry logic for
      short writes, but this is never called as the client is told the
      complete write succeeded.
      
      There are probably other ways it could happen, but in my case it
      happened with a fuse (filesystem in userspace) filesystem which can
      rather easily have a partial write.
      
      Here is a patch to properly return the short write count to the
      client.
      Signed-off-by: default avatarDavid Shaw <dshaw@jabberwocky.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      31dec253
    • Qinghuang Feng's avatar
      NFSD: cleanup for nfs3proc.c · 12214cb7
      Qinghuang Feng authored
      
      MSDOS_SUPER_MAGIC is defined in <linux/magic.h>,
      so use MSDOS_SUPER_MAGIC directly.
      Signed-off-by: default avatarQinghuang Feng <qhfeng.kernel@gmail.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      12214cb7
  8. 29 Sep, 2008 1 commit
    • J. Bruce Fields's avatar
      nfsd: permit unauthenticated stat of export root · 04716e66
      J. Bruce Fields authored
      
      RFC 2623 section 2.3.2 permits the server to bypass gss authentication
      checks for certain operations that a client may perform when mounting.
      In the case of a client that doesn't have some form of credentials
      available to it on boot, this allows it to perform the mount unattended.
      (Presumably real file access won't be needed until a user with
      credentials logs in.)
      
      Being slightly more lenient allows lots of old clients to access
      krb5-only exports, with the only loss being a small amount of
      information leaked about the root directory of the export.
      
      This affects only v2 and v3; v4 still requires authentication for all
      access.
      
      Thanks to Peter Staubach testing against a Solaris client, which
      suggesting addition of v3 getattr, to the list, and to Trond for noting
      that doing so exposes no additional information.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Cc: Peter Staubach <staubach@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      04716e66
  9. 23 Jun, 2008 1 commit
  10. 15 Feb, 2008 1 commit
  11. 09 May, 2007 1 commit
    • Jeff Layton's avatar
      RPC: add wrapper for svc_reserve to account for checksum · cd123012
      Jeff Layton authored
      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: default avatarJeff Layton <jlayton@redhat.com>
      Acked-by: default avatarNeil Brown <neilb@suse.de>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Acked-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd123012
  12. 08 Nov, 2006 1 commit
  13. 20 Oct, 2006 2 commits
  14. 04 Oct, 2006 2 commits
  15. 11 Apr, 2006 1 commit
  16. 06 Jan, 2006 1 commit
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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