1. 29 4月, 2009 1 次提交
  2. 04 4月, 2009 14 次提交
  3. 19 3月, 2009 2 次提交
  4. 18 3月, 2009 1 次提交
  5. 08 1月, 2009 1 次提交
  6. 30 9月, 2008 6 次提交
  7. 19 7月, 2008 2 次提交
  8. 05 7月, 2008 1 次提交
  9. 03 7月, 2008 4 次提交
  10. 24 6月, 2008 1 次提交
    • B
      nfsd: make nfs4xdr WRITEMEM safe against zero count · 13b1867c
      Benny Halevy 提交于
      WRITEMEM zeroes the last word in the destination buffer
      for padding purposes, but this must not be done if
      no bytes are to be copied, as it would result
      in zeroing of the word right before the array.
      
      The current implementation works since it's always called
      with non zero nbytes or it follows an encoding of the
      string (or opaque) length which, if equal to zero,
      can be overwritten with zero.
      
      Nevertheless, it seems safer to check for this case.
      Signed-off-by: NBenny Halevy <bhalevy@panasas.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      13b1867c
  11. 26 4月, 2008 1 次提交
  12. 24 4月, 2008 1 次提交
  13. 15 2月, 2008 1 次提交
  14. 02 2月, 2008 2 次提交
    • F
      nfsd: Allow AIX client to read dir containing mountpoints · 406a7ea9
      Frank Filz 提交于
      This patch addresses a compatibility issue with a Linux NFS server and
      AIX NFS client.
      
      I have exported /export as fsid=0 with sec=krb5:krb5i
      I have mount --bind /home onto /export/home
      I have exported /export/home with sec=krb5i
      
      The AIX client mounts / -o sec=krb5:krb5i onto /mnt
      
      If I do an ls /mnt, the AIX client gets a permission error. Looking at
      the network traceIwe see a READDIR looking for attributes
      FATTR4_RDATTR_ERROR and FATTR4_MOUNTED_ON_FILEID. The response gives a
      NFS4ERR_WRONGSEC which the AIX client is not expecting.
      
      Since the AIX client is only asking for an attribute that is an
      attribute of the parent file system (pseudo root in my example), it
      seems reasonable that there should not be an error.
      
      In discussing this issue with Bruce Fields, I initially proposed
      ignoring the error in nfsd4_encode_dirent_fattr() if all that was being
      asked for was FATTR4_RDATTR_ERROR and FATTR4_MOUNTED_ON_FILEID, however,
      Bruce suggested that we avoid calling cross_mnt() if only these
      attributes are requested.
      
      The following patch implements bypassing cross_mnt() if only
      FATTR4_RDATTR_ERROR and FATTR4_MOUNTED_ON_FILEID are called. Since there
      is some complexity in the code in nfsd4_encode_fattr(), I didn't want to
      duplicate code (and introduce a maintenance nightmare), so I added a
      parameter to nfsd4_encode_fattr() that indicates whether it should
      ignore cross mounts and simply fill in the attribute using the passed in
      dentry as opposed to it's parent.
      Signed-off-by: NFrank Filz <ffilzlnx@us.ibm.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      406a7ea9
    • J
      nfsd: Fix handling of negative lengths in read_buf() · ca2a05aa
      J. Bruce Fields 提交于
      The length "nbytes" passed into read_buf should never be negative, but
      we check only for too-large values of "nbytes", not for too-small
      values.  Make nbytes unsigned, so it's clear that the former tests are
      sufficient.  (Despite this read_buf() currently correctly returns an xdr
      error in the case of a negative length, thanks to an unsigned
      comparison with size_of() and bounds-checking in kmalloc().  This seems
      very fragile, though.)
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      ca2a05aa
  15. 10 10月, 2007 2 次提交
    • J
      knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME · a16e92ed
      J. Bruce Fields 提交于
      Without this we always return 2^32-1 as the the maximum namelength.
      
      Thanks to Andreas Gruenbacher for bug report and testing.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Cc: Andreas Gruenbacher <agruen@suse.de>
      a16e92ed
    • P
      knfsd: 64 bit ino support for NFS server · 40ee5dc6
      Peter Staubach 提交于
      Modify the NFS server code to support 64 bit ino's, as
      appropriate for the system and the NFS protocol version.
      
      The gist of the changes is to query the underlying file system
      for attributes and not just to use the cached attributes in the
      inode.  For this specific purpose, the inode only contains an
      ino field which unsigned long, which is large enough on 64 bit
      platforms, but is not large enough on 32 bit platforms.
      
      I haven't been able to find any reason why ->getattr can't be called
      while i_mutex.  The specification indicates that i_mutex is not
      required to be held in order to invoke ->getattr, but it doesn't say
      that i_mutex can't be held while invoking ->getattr.
      
      I also haven't come to any conclusions regarding the value of
      lease_get_mtime() and whether it should or should not be invoked
      by fill_post_wcc() too.  I chose not to change this because I
      thought that it was safer to leave well enough alone.  If we
      decide to make a change, it can be done separately.
      Signed-off-by: NPeter Staubach <staubach@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Acked-by: NNeil Brown <neilb@suse.de>
      40ee5dc6