1. 12 6月, 2020 5 次提交
  2. 27 5月, 2020 4 次提交
  3. 15 5月, 2020 1 次提交
    • O
      NFSv3: fix rpc receive buffer size for MOUNT call · 8eed292b
      Olga Kornievskaia 提交于
      Prior to commit e3d3ab64dd66 ("SUNRPC: Use au_rslack when
      computing reply buffer size"), there was enough slack in the reply
      buffer to commodate filehandles of size 60bytes. However, the real
      problem was that the reply buffer size for the MOUNT operation was
      not correctly calculated. Received buffer size used the filehandle
      size for NFSv2 (32bytes) which is much smaller than the allowed
      filehandle size for the v3 mounts.
      
      Fix the reply buffer size (decode arguments size) for the MNT command.
      
      Fixes: 2c94b8ec ("SUNRPC: Use au_rslack when computing reply buffer size")
      Signed-off-by: NOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      8eed292b
  4. 13 5月, 2020 1 次提交
  5. 12 5月, 2020 2 次提交
  6. 09 5月, 2020 3 次提交
    • D
      NFSv4: Fix fscache cookie aux_data to ensure change_attr is included · 50eaa652
      Dave Wysochanski 提交于
      Commit 402cb8dd ("fscache: Attach the index key and aux data to
      the cookie") added the aux_data and aux_data_len to parameters to
      fscache_acquire_cookie(), and updated the callers in the NFS client.
      In the process it modified the aux_data to include the change_attr,
      but missed adding change_attr to a couple places where aux_data was
      used.  Specifically, when opening a file and the change_attr is not
      added, the following attempt to lookup an object will fail inside
      cachefiles_check_object_xattr() = -116 due to
      nfs_fscache_inode_check_aux() failing memcmp on auxdata and returning
      FSCACHE_CHECKAUX_OBSOLETE.
      
      Fix this by adding nfs_fscache_update_auxdata() to set the auxdata
      from all relevant fields in the inode, including the change_attr.
      
      Fixes: 402cb8dd ("fscache: Attach the index key and aux data to the cookie")
      Signed-off-by: NDave Wysochanski <dwysocha@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      50eaa652
    • D
      NFS: Fix fscache super_cookie allocation · 15751612
      Dave Wysochanski 提交于
      Commit f2aedb71 ("NFS: Add fs_context support.") reworked
      NFS mount code paths for fs_context support which included
      super_block initialization.  In the process there was an extra
      return left in the code and so we never call
      nfs_fscache_get_super_cookie even if 'fsc' is given on as mount
      option.  In addition, there is an extra check inside
      nfs_fscache_get_super_cookie for the NFS_OPTION_FSCACHE which
      is unnecessary since the only caller nfs_get_cache_cookie
      checks this flag.
      
      Fixes: f2aedb71 ("NFS: Add fs_context support.")
      Signed-off-by: NDave Wysochanski <dwysocha@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      15751612
    • D
      NFS: Fix fscache super_cookie index_key from changing after umount · d9bfced1
      Dave Wysochanski 提交于
      Commit 402cb8dd ("fscache: Attach the index key and aux data to
      the cookie") added the index_key and index_key_len parameters to
      fscache_acquire_cookie(), and updated the callers in the NFS client.
      One of the callers was inside nfs_fscache_get_super_cookie()
      and was changed to use the full struct nfs_fscache_key as the
      index_key.  However, a couple members of this structure contain
      pointers and thus will change each time the same NFS share is
      remounted.  Since index_key is used for fscache_cookie->key_hash
      and this subsequently is used to compare cookies, the effectiveness
      of fscache with NFS is reduced to the point at which a umount
      occurs.   Any subsequent remount of the same share will cause a
      unique NFS super_block index_key and key_hash to be generated for
      the same data, rendering any prior fscache data unable to be
      found.  A simple reproducer demonstrates the problem.
      
      1. Mount share with 'fsc', create a file, drop page cache
      systemctl start cachefilesd
      mount -o vers=3,fsc 127.0.0.1:/export /mnt
      dd if=/dev/zero of=/mnt/file1.bin bs=4096 count=1
      echo 3 > /proc/sys/vm/drop_caches
      
      2. Read file into page cache and fscache, then unmount
      dd if=/mnt/file1.bin of=/dev/null bs=4096 count=1
      umount /mnt
      
      3. Remount and re-read which should come from fscache
      mount -o vers=3,fsc 127.0.0.1:/export /mnt
      echo 3 > /proc/sys/vm/drop_caches
      dd if=/mnt/file1.bin of=/dev/null bs=4096 count=1
      
      4. Check for READ ops in mountstats - there should be none
      grep READ: /proc/self/mountstats
      
      Looking at the history and the removed function, nfs_super_get_key(),
      we should only use nfs_fscache_key.key plus any uniquifier, for
      the fscache index_key.
      
      Fixes: 402cb8dd ("fscache: Attach the index key and aux data to the cookie")
      Signed-off-by: NDave Wysochanski <dwysocha@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d9bfced1
  7. 01 5月, 2020 1 次提交
  8. 29 4月, 2020 1 次提交
  9. 25 4月, 2020 1 次提交
  10. 20 4月, 2020 3 次提交
  11. 14 4月, 2020 1 次提交
  12. 11 4月, 2020 1 次提交
  13. 07 4月, 2020 1 次提交
  14. 04 4月, 2020 3 次提交
  15. 03 4月, 2020 3 次提交
  16. 02 4月, 2020 9 次提交