1. 08 10月, 2016 2 次提交
  2. 05 8月, 2016 2 次提交
    • J
      nfsd: reorganize nfsd_create · b44061d0
      J. Bruce Fields 提交于
      There's some odd logic in nfsd_create() that allows it to be called with
      the parent directory either locked or unlocked.  The only already-locked
      caller is NFSv2's nfsd_proc_create().  It's less confusing to split out
      the unlocked case into a separate function which the NFSv2 code can call
      directly.
      
      Also fix some comments while we're here.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b44061d0
    • J
      nfsd: remove redundant zero-length check from create · 12391d07
      J. Bruce Fields 提交于
      lookup_one_len already has this check.
      
      The only effect of this patch is to return access instead of perm in the
      0-length-filename case.  I actually prefer nfserr_perm (or _inval?), but
      I doubt anyone cares.
      
      The isdotent check seems redundant too, but I worry that some client
      might actually care about that strange nfserr_exist error.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      12391d07
  3. 29 5月, 2015 1 次提交
  4. 16 4月, 2015 1 次提交
  5. 30 7月, 2014 1 次提交
  6. 10 7月, 2014 1 次提交
    • J
      nfsd: add a nfserrno mapping for -E2BIG to nfserr_fbig · 62814d6a
      Jeff Layton 提交于
      I saw this pop up with some pynfs testing:
      
          [  123.609992] nfsd: non-standard errno: -7
      
      ...and -7 is -E2BIG. I think what happened is that XFS returned -E2BIG
      due to some xattr operations with the ACL10 pynfs TEST (I guess it has
      limited xattr size?).
      
      Add a better mapping for that error since it's possible that we'll need
      it. How about we convert it to NFSERR_FBIG? As Bruce points out, they
      both have "BIG" in the name so it must be good.
      
      Also, turn the printk in this function into a WARN() so that we can get
      a bit more information about situations that don't have proper mappings.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      62814d6a
  7. 09 7月, 2014 3 次提交
  8. 26 2月, 2013 1 次提交
  9. 31 7月, 2012 1 次提交
  10. 05 1月, 2011 4 次提交
  11. 31 7月, 2010 1 次提交
  12. 30 7月, 2010 1 次提交
  13. 16 12月, 2009 1 次提交
  14. 15 12月, 2009 2 次提交
  15. 14 11月, 2009 1 次提交
  16. 29 9月, 2009 1 次提交
    • J
      nfsd4: fix error return when pseudoroot missing · f39bde24
      J. Bruce Fields 提交于
      We really shouldn't hit this case at all, and forthcoming kernel and
      nfs-utils changes should eliminate this case; if it does happen,
      consider it a bug rather than reporting an error that doesn't really
      make sense for the operation (since there's no reason for a server to be
      accepting v4 traffic yet have no root filehandle).
      
      Also move some exp_pseudoroot code into a helper function while we're
      here.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      f39bde24
  17. 16 6月, 2009 1 次提交
  18. 19 3月, 2009 1 次提交
    • D
      Short write in nfsd becomes a full write to the client · 31dec253
      David Shaw 提交于
      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: NDavid Shaw <dshaw@jabberwocky.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      31dec253
  19. 08 1月, 2009 1 次提交
  20. 30 9月, 2008 1 次提交
    • J
      nfsd: permit unauthenticated stat of export root · 04716e66
      J. Bruce Fields 提交于
      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: NJ. Bruce Fields <bfields@citi.umich.edu>
      Cc: Peter Staubach <staubach@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      04716e66
  21. 24 6月, 2008 2 次提交
    • M
      nfsd: rename MAY_ flags · 8837abca
      Miklos Szeredi 提交于
      Rename nfsd_permission() specific MAY_* flags to NFSD_MAY_* to make it
      clear, that these are not used outside nfsd, and to avoid name and
      number space conflicts with the VFS.
      
      [comment from hch: rename MAY_READ, MAY_WRITE and MAY_EXEC as well]
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      8837abca
    • N
      knfsd: nfsd: Handle ERESTARTSYS from syscalls. · 599eb304
      NeilBrown 提交于
      OCFS2 can return -ERESTARTSYS from write requests (and possibly
      elsewhere) if there is a signal pending.
      
      If nfsd is shutdown (by sending a signal to each thread) while there
      is still an IO load from the client, each thread could handle one last
      request with a signal pending.  This can result in -ERESTARTSYS
      which is not understood by nfserrno() and so is reflected back to
      the client as nfserr_io aka -EIO.  This is wrong.
      
      Instead, interpret ERESTARTSYS to mean "try again later" by returning
      nfserr_jukebox.  The client will resend and - if the server is
      restarted - the write will (hopefully) be successful and everyone will
      be happy.
      
       The symptom that I narrowed down to this was:
          copy a large file via NFS to an OCFS2 filesystem, and restart
          the nfs server during the copy.
          The 'cp' might get an -EIO, and the file will be corrupted -
          presumably holes in the middle where writes appeared to fail.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      599eb304
  22. 15 2月, 2008 1 次提交
  23. 18 7月, 2007 1 次提交
  24. 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
  25. 13 2月, 2007 1 次提交
  26. 21 10月, 2006 3 次提交
  27. 04 10月, 2006 3 次提交