1. 17 1月, 2020 2 次提交
  2. 24 11月, 2019 1 次提交
  3. 13 11月, 2019 1 次提交
  4. 06 11月, 2019 4 次提交
    • T
      NFS: Fix an RCU lock leak in nfs4_refresh_delegation_stateid() · 74001646
      Trond Myklebust 提交于
      commit 79cc55422ce99be5964bde208ba8557174720893 upstream.
      
      A typo in nfs4_refresh_delegation_stateid() means we're leaking an
      RCU lock, and always returning a value of 'false'. As the function
      description states, we were always supposed to return 'true' if a
      matching delegation was found.
      
      Fixes: 12f275cd ("NFSv4: Retry CLOSE and DELEGRETURN on NFS4ERR_OLD_STATEID.")
      Cc: stable@vger.kernel.org # v4.15+
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74001646
    • C
      NFSv4: Fix leak of clp->cl_acceptor string · da24be88
      Chuck Lever 提交于
      [ Upstream commit 1047ec868332034d1fbcb2fae19fe6d4cb869ff2 ]
      
      Our client can issue multiple SETCLIENTID operations to the same
      server in some circumstances. Ensure that calls to
      nfs4_proc_setclientid() after the first one do not overwrite the
      previously allocated cl_acceptor string.
      
      unreferenced object 0xffff888461031800 (size 32):
        comm "mount.nfs", pid 2227, jiffies 4294822467 (age 1407.749s)
        hex dump (first 32 bytes):
          6e 66 73 40 6b 6c 69 6d 74 2e 69 62 2e 31 30 31  nfs@klimt.ib.101
          35 67 72 61 6e 67 65 72 2e 6e 65 74 00 00 00 00  5granger.net....
        backtrace:
          [<00000000ab820188>] __kmalloc+0x128/0x176
          [<00000000eeaf4ec8>] gss_stringify_acceptor+0xbd/0x1a7 [auth_rpcgss]
          [<00000000e85e3382>] nfs4_proc_setclientid+0x34e/0x46c [nfsv4]
          [<000000003d9cf1fa>] nfs40_discover_server_trunking+0x7a/0xed [nfsv4]
          [<00000000b81c3787>] nfs4_discover_server_trunking+0x81/0x244 [nfsv4]
          [<000000000801b55f>] nfs4_init_client+0x1b0/0x238 [nfsv4]
          [<00000000977daf7f>] nfs4_set_client+0xfe/0x14d [nfsv4]
          [<0000000053a68a2a>] nfs4_create_server+0x107/0x1db [nfsv4]
          [<0000000088262019>] nfs4_remote_mount+0x2c/0x59 [nfsv4]
          [<00000000e84a2fd0>] legacy_get_tree+0x2d/0x4c
          [<00000000797e947c>] vfs_get_tree+0x20/0xc7
          [<00000000ecabaaa8>] fc_mount+0xe/0x36
          [<00000000f15fafc2>] vfs_kern_mount+0x74/0x8d
          [<00000000a3ff4e26>] nfs_do_root_mount+0x8a/0xa3 [nfsv4]
          [<00000000d1c2b337>] nfs4_try_mount+0x58/0xad [nfsv4]
          [<000000004c9bddee>] nfs_fs_mount+0x820/0x869 [nfs]
      
      Fixes: f11b2a1c ("nfs4: copy acceptor name from context ... ")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      da24be88
    • Z
      nfs: Fix nfsi->nrequests count error on nfs_inode_remove_request · ca2cc4b4
      ZhangXiaoxu 提交于
      [ Upstream commit 33ea5aaa87cdae0f9af4d6b7ee4f650a1a36fd1d ]
      
      When xfstests testing, there are some WARNING as below:
      
      WARNING: CPU: 0 PID: 6235 at fs/nfs/inode.c:122 nfs_clear_inode+0x9c/0xd8
      Modules linked in:
      CPU: 0 PID: 6235 Comm: umount.nfs
      Hardware name: linux,dummy-virt (DT)
      pstate: 60000005 (nZCv daif -PAN -UAO)
      pc : nfs_clear_inode+0x9c/0xd8
      lr : nfs_evict_inode+0x60/0x78
      sp : fffffc000f68fc00
      x29: fffffc000f68fc00 x28: fffffe00c53155c0
      x27: fffffe00c5315000 x26: fffffc0009a63748
      x25: fffffc000f68fd18 x24: fffffc000bfaaf40
      x23: fffffc000936d3c0 x22: fffffe00c4ff5e20
      x21: fffffc000bfaaf40 x20: fffffe00c4ff5d10
      x19: fffffc000c056000 x18: 000000000000003c
      x17: 0000000000000000 x16: 0000000000000000
      x15: 0000000000000040 x14: 0000000000000228
      x13: fffffc000c3a2000 x12: 0000000000000045
      x11: 0000000000000000 x10: 0000000000000000
      x9 : 0000000000000000 x8 : 0000000000000000
      x7 : 0000000000000000 x6 : fffffc00084b027c
      x5 : fffffc0009a64000 x4 : fffffe00c0e77400
      x3 : fffffc000c0563a8 x2 : fffffffffffffffb
      x1 : 000000000000764e x0 : 0000000000000001
      Call trace:
       nfs_clear_inode+0x9c/0xd8
       nfs_evict_inode+0x60/0x78
       evict+0x108/0x380
       dispose_list+0x70/0xa0
       evict_inodes+0x194/0x210
       generic_shutdown_super+0xb0/0x220
       nfs_kill_super+0x40/0x88
       deactivate_locked_super+0xb4/0x120
       deactivate_super+0x144/0x160
       cleanup_mnt+0x98/0x148
       __cleanup_mnt+0x38/0x50
       task_work_run+0x114/0x160
       do_notify_resume+0x2f8/0x308
       work_pending+0x8/0x14
      
      The nrequest should be increased/decreased only if PG_INODE_REF flag
      was setted.
      
      But in the nfs_inode_remove_request function, it maybe decrease when
      no PG_INODE_REF flag, this maybe lead nrequests count error.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca2cc4b4
    • T
      NFSv4: Ensure that the state manager exits the loop on SIGKILL · ce05beb3
      Trond Myklebust 提交于
      [ Upstream commit a1aa09be21fa344d1f5585aab8164bfae55f57e3 ]
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ce05beb3
  5. 18 10月, 2019 1 次提交
  6. 12 10月, 2019 2 次提交
  7. 21 9月, 2019 5 次提交
  8. 16 9月, 2019 1 次提交
  9. 06 9月, 2019 4 次提交
  10. 29 8月, 2019 2 次提交
  11. 16 8月, 2019 1 次提交
  12. 04 8月, 2019 4 次提交
  13. 26 7月, 2019 4 次提交
  14. 14 7月, 2019 1 次提交
  15. 03 7月, 2019 1 次提交
  16. 11 6月, 2019 2 次提交
  17. 31 5月, 2019 4 次提交