1. 15 1月, 2020 5 次提交
  2. 02 10月, 2019 1 次提交
    • Z
      nfs: Fix nfsi->nrequests count error on nfs_inode_remove_request · 33ea5aaa
      ZhangXiaoxu 提交于
      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>
      33ea5aaa
  3. 27 8月, 2019 3 次提交
  4. 19 8月, 2019 1 次提交
  5. 07 7月, 2019 1 次提交
  6. 21 5月, 2019 1 次提交
  7. 26 4月, 2019 6 次提交
  8. 21 2月, 2019 3 次提交
  9. 13 2月, 2019 1 次提交
  10. 30 1月, 2019 1 次提交
  11. 29 12月, 2018 1 次提交
  12. 20 12月, 2018 2 次提交
    • N
      NFS/NFSD/SUNRPC: replace generic creds with 'struct cred'. · a52458b4
      NeilBrown 提交于
      SUNRPC has two sorts of credentials, both of which appear as
      "struct rpc_cred".
      There are "generic credentials" which are supplied by clients
      such as NFS and passed in 'struct rpc_message' to indicate
      which user should be used to authorize the request, and there
      are low-level credentials such as AUTH_NULL, AUTH_UNIX, AUTH_GSS
      which describe the credential to be sent over the wires.
      
      This patch replaces all the generic credentials by 'struct cred'
      pointers - the credential structure used throughout Linux.
      
      For machine credentials, there is a special 'struct cred *' pointer
      which is statically allocated and recognized where needed as
      having a special meaning.  A look-up of a low-level cred will
      map this to a machine credential.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Acked-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      a52458b4
    • N
      NFS: move credential expiry tracking out of SUNRPC into NFS. · ddf529ee
      NeilBrown 提交于
      NFS needs to know when a credential is about to expire so that
      it can modify write-back behaviour to finish the write inside the
      expiry time.
      It currently uses functions in SUNRPC code which make use of a
      fairly complex callback scheme and flags in the generic credientials.
      
      As I am working to discard the generic credentials, this has to change.
      
      This patch moves the logic into NFS, in part by finding and caching
      the low-level credential in the open_context.  We then make direct
      cred-api calls on that.
      
      This makes the code much simpler and removes a dependency on generic
      rpc credentials.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      ddf529ee
  13. 27 7月, 2018 1 次提交
  14. 01 6月, 2018 2 次提交
  15. 11 4月, 2018 2 次提交
  16. 20 3月, 2018 1 次提交
  17. 09 3月, 2018 1 次提交
    • T
      NFS: Fix unstable write completion · c4f24df9
      Trond Myklebust 提交于
      We do want to respect the FLUSH_SYNC argument to nfs_commit_inode() to
      ensure that all outstanding COMMIT requests to the inode in question are
      complete. Currently we may exit early from both nfs_commit_inode() and
      nfs_write_inode() even if there are COMMIT requests in flight, or unstable
      writes on the commit list.
      
      In order to get the right semantics w.r.t. sync_inode(), we don't need
      to have nfs_commit_inode() reset the inode dirty flags when called from
      nfs_wb_page() and/or nfs_wb_all(). We just need to ensure that
      nfs_write_inode() leaves them in the right state if there are outstanding
      commits, or stable pages.
      Reported-by: NScott Mayhew <smayhew@redhat.com>
      Fixes: dc4fd9ab ("nfs: don't wait on commit in nfs_commit_inode()...")
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      c4f24df9
  18. 29 1月, 2018 1 次提交
  19. 15 1月, 2018 1 次提交
  20. 16 12月, 2017 1 次提交
    • S
      nfs: don't wait on commit in nfs_commit_inode() if there were no commit requests · dc4fd9ab
      Scott Mayhew 提交于
      If there were no commit requests, then nfs_commit_inode() should not
      wait on the commit or mark the inode dirty, otherwise the following
      BUG_ON can be triggered:
      
      [ 1917.130762] kernel BUG at fs/inode.c:578!
      [ 1917.130766] Oops: Exception in kernel mode, sig: 5 [#1]
      [ 1917.130768] SMP NR_CPUS=2048 NUMA pSeries
      [ 1917.130772] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi blocklayoutdriver rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc sg nx_crypto pseries_rng ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common ibmvscsi scsi_transport_srp ibmveth scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
      [ 1917.130805] CPU: 2 PID: 14923 Comm: umount.nfs4 Tainted: G               ------------ T 3.10.0-768.el7.ppc64 #1
      [ 1917.130810] task: c0000005ecd88040 ti: c00000004cea0000 task.ti: c00000004cea0000
      [ 1917.130813] NIP: c000000000354178 LR: c000000000354160 CTR: c00000000012db80
      [ 1917.130816] REGS: c00000004cea3720 TRAP: 0700   Tainted: G               ------------ T  (3.10.0-768.el7.ppc64)
      [ 1917.130820] MSR: 8000000100029032 <SF,EE,ME,IR,DR,RI>  CR: 22002822  XER: 20000000
      [ 1917.130828] CFAR: c00000000011f594 SOFTE: 1
      GPR00: c000000000354160 c00000004cea39a0 c0000000014c4700 c0000000018cc750
      GPR04: 000000000000c750 80c0000000000000 0600000000000000 04eeb76bea749a03
      GPR08: 0000000000000034 c0000000018cc758 0000000000000001 d000000005e619e8
      GPR12: c00000000012db80 c000000007b31200 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR24: 0000000000000000 c000000000dfc3ec 0000000000000000 c0000005eefc02c0
      GPR28: d0000000079dbd50 c0000005b94a02c0 c0000005b94a0250 c0000005b94a01c8
      [ 1917.130867] NIP [c000000000354178] .evict+0x1c8/0x350
      [ 1917.130871] LR [c000000000354160] .evict+0x1b0/0x350
      [ 1917.130873] Call Trace:
      [ 1917.130876] [c00000004cea39a0] [c000000000354160] .evict+0x1b0/0x350 (unreliable)
      [ 1917.130880] [c00000004cea3a30] [c0000000003558cc] .evict_inodes+0x13c/0x270
      [ 1917.130884] [c00000004cea3af0] [c000000000327d20] .kill_anon_super+0x70/0x1e0
      [ 1917.130896] [c00000004cea3b80] [d000000005e43e30] .nfs_kill_super+0x20/0x60 [nfs]
      [ 1917.130900] [c00000004cea3c00] [c000000000328a20] .deactivate_locked_super+0xa0/0x1b0
      [ 1917.130903] [c00000004cea3c80] [c00000000035ba54] .cleanup_mnt+0xd4/0x180
      [ 1917.130907] [c00000004cea3d10] [c000000000119034] .task_work_run+0x114/0x150
      [ 1917.130912] [c00000004cea3db0] [c00000000001ba6c] .do_notify_resume+0xcc/0x100
      [ 1917.130916] [c00000004cea3e30] [c00000000000a7b0] .ret_from_except_lite+0x5c/0x60
      [ 1917.130919] Instruction dump:
      [ 1917.130921] 7fc3f378 486734b5 60000000 387f00a0 38800003 4bdcb365 60000000 e95f00a0
      [ 1917.130927] 694a0060 7d4a0074 794ad182 694a0001 <0b0a0000> 892d02a4 2f890000 40de0134
      Signed-off-by: NScott Mayhew <smayhew@redhat.com>
      Cc: stable@vger.kernel.org # 4.5+
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      dc4fd9ab
  21. 18 11月, 2017 1 次提交
  22. 12 9月, 2017 2 次提交
    • N
      NFS: various changes relating to reporting IO errors. · bf4b4905
      NeilBrown 提交于
      1/ remove 'start' and 'end' args from nfs_file_fsync_commit().
         They aren't used.
      
      2/ Make nfs_context_set_write_error() a "static inline" in internal.h
         so we can...
      
      3/ Use nfs_context_set_write_error() instead of mapping_set_error()
         if nfs_pageio_add_request() fails before sending any request.
         NFS generally keeps errors in the open_context, not the mapping,
         so this is more consistent.
      
      4/ If filemap_write_and_write_range() reports any error, still
         check ctx->error.  The value in ctx->error is likely to be
         more useful.  As part of this, NFS_CONTEXT_ERROR_WRITE is
         cleared slightly earlier, before nfs_file_fsync_commit() is called,
         rather than at the start of that function.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      bf4b4905
    • C
      NFS: Add static NFS I/O tracepoints · 8224b273
      Chuck Lever 提交于
      Tools like tcpdump and rpcdebug can be very useful. But there are
      plenty of environments where they are difficult or impossible to
      use. For example, we've had customers report I/O failures during
      workloads so heavy that collecting network traffic or enabling
      RPC debugging are themselves onerous.
      
      The kernel's static tracepoints are lightweight (less likely to
      introduce timing changes) and efficient (the trace data is compact).
      They also work in scenarios where capturing network traffic is not
      possible due to lack of hardware support (some InfiniBand HCAs) or
      where data or network privacy is a concern.
      
      Introduce tracepoints that show when an NFS READ, WRITE, or COMMIT
      is initiated, and when it completes. Record the arguments and
      results of each operation, which are not shown by existing sunrpc
      module's tracepoints.
      
      For instance, the recorded offset and count can be used to match an
      "initiate" event to a "done" event. If an NFS READ result returns
      fewer bytes than requested or zero, seeing the EOF flag can be
      probative. Seeing an NFS4ERR_BAD_STATEID result is also indication
      of a particular class of problems. The timing information attached
      to each event record can often be useful as well.
      
      Usage example:
      
      [root@manet tmp]# trace-cmd record -e nfs:*initiate* -e nfs:*done
      /sys/kernel/debug/tracing/events/nfs/*initiate*/filter
      /sys/kernel/debug/tracing/events/nfs/*done/filter
      Hit Ctrl^C to stop recording
      ^CKernel buffer statistics:
        Note: "entries" are the entries left in the kernel ring buffer and are not
              recorded in the trace data. They should all be zero.
      
      CPU: 0
      entries: 0
      overrun: 0
      commit overrun: 0
      bytes: 3680
      oldest event ts:    78.367422
      now ts:   100.124419
      dropped events: 0
      read events: 74
      
      ... and so on.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      8224b273
  23. 10 9月, 2017 1 次提交