1. 18 5月, 2020 9 次提交
  2. 10 5月, 2020 1 次提交
  3. 08 5月, 2020 1 次提交
  4. 21 4月, 2020 1 次提交
    • W
      blk-iocost: Fix error on iocost_ioc_vrate_adj · d6c8e949
      Waiman Long 提交于
      Systemtap 4.2 is unable to correctly interpret the "u32 (*missed_ppm)[2]"
      argument of the iocost_ioc_vrate_adj trace entry defined in
      include/trace/events/iocost.h leading to the following error:
      
        /tmp/stapAcz0G0/stap_c89c58b83cea1724e26395efa9ed4939_6321_aux_6.c:78:8:
        error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
         , u32[]* __tracepoint_arg_missed_ppm
      
      That argument type is indeed rather complex and hard to read. Looking
      at block/blk-iocost.c. It is just a 2-entry u32 array. By simplifying
      the argument to a simple "u32 *missed_ppm" and adjusting the trace
      entry accordingly, the compilation error was gone.
      
      Fixes: 7caa4715 ("blkcg: implement blk-iocost")
      Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      d6c8e949
  5. 20 4月, 2020 1 次提交
    • C
      xprtrdma: Fix trace point use-after-free race · bdb2ce82
      Chuck Lever 提交于
      It's not safe to use resources pointed to by the @send_wr of
      ib_post_send() _after_ that function returns. Those resources are
      typically freed by the Send completion handler, which can run before
      ib_post_send() returns.
      
      Thus the trace points currently around ib_post_send() in the
      client's RPC/RDMA transport are a hazard, even when they are
      disabled. Rearrange them so that they touch the Work Request only
      _before_ ib_post_send() is invoked.
      
      Fixes: ab03eff5 ("xprtrdma: Add trace points in RPC Call transmit paths")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      bdb2ce82
  6. 18 4月, 2020 2 次提交
    • Z
      buffer: remove useless comment and WB_REASON_FREE_MORE_MEM, reason. · c4b4c2a7
      Zhiqiang Liu 提交于
      free_more_memory func has been completely removed in commit bc48f001
      ("buffer: eliminate the need to call free_more_memory() in __getblk_slow()")
      
      So comment and `WB_REASON_FREE_MORE_MEM` reason about free_more_memory
      are no longer needed.
      
      Fixes: bc48f001 ("buffer: eliminate the need to call free_more_memory() in __getblk_slow()")
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NZhiqiang Liu <liuzhiqiang26@huawei.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c4b4c2a7
    • C
      svcrdma: Fix trace point use-after-free race · e28b4fc6
      Chuck Lever 提交于
      I hit this while testing nfsd-5.7 with kernel memory debugging
      enabled on my server:
      
      Mar 30 13:21:45 klimt kernel: BUG: unable to handle page fault for address: ffff8887e6c279a8
      Mar 30 13:21:45 klimt kernel: #PF: supervisor read access in kernel mode
      Mar 30 13:21:45 klimt kernel: #PF: error_code(0x0000) - not-present page
      Mar 30 13:21:45 klimt kernel: PGD 3601067 P4D 3601067 PUD 87c519067 PMD 87c3e2067 PTE 800ffff8193d8060
      Mar 30 13:21:45 klimt kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
      Mar 30 13:21:45 klimt kernel: CPU: 2 PID: 1933 Comm: nfsd Not tainted 5.6.0-rc6-00040-g881e87a3c6f9 #1591
      Mar 30 13:21:45 klimt kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
      Mar 30 13:21:45 klimt kernel: RIP: 0010:svc_rdma_post_chunk_ctxt+0xab/0x284 [rpcrdma]
      Mar 30 13:21:45 klimt kernel: Code: c1 83 34 02 00 00 29 d0 85 c0 7e 72 48 8b bb a0 02 00 00 48 8d 54 24 08 4c 89 e6 48 8b 07 48 8b 40 20 e8 5a 5c 2b e1 41 89 c6 <8b> 45 20 89 44 24 04 8b 05 02 e9 01 00 85 c0 7e 33 e9 5e 01 00 00
      Mar 30 13:21:45 klimt kernel: RSP: 0018:ffffc90000dfbdd8 EFLAGS: 00010286
      Mar 30 13:21:45 klimt kernel: RAX: 0000000000000000 RBX: ffff8887db8db400 RCX: 0000000000000030
      Mar 30 13:21:45 klimt kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000246
      Mar 30 13:21:45 klimt kernel: RBP: ffff8887e6c27988 R08: 0000000000000000 R09: 0000000000000004
      Mar 30 13:21:45 klimt kernel: R10: ffffc90000dfbdd8 R11: 00c068ef00000000 R12: ffff8887eb4e4a80
      Mar 30 13:21:45 klimt kernel: R13: ffff8887db8db634 R14: 0000000000000000 R15: ffff8887fc931000
      Mar 30 13:21:45 klimt kernel: FS:  0000000000000000(0000) GS:ffff88885bd00000(0000) knlGS:0000000000000000
      Mar 30 13:21:45 klimt kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      Mar 30 13:21:45 klimt kernel: CR2: ffff8887e6c279a8 CR3: 000000081b72e002 CR4: 00000000001606e0
      Mar 30 13:21:45 klimt kernel: Call Trace:
      Mar 30 13:21:45 klimt kernel: ? svc_rdma_vec_to_sg+0x7f/0x7f [rpcrdma]
      Mar 30 13:21:45 klimt kernel: svc_rdma_send_write_chunk+0x59/0xce [rpcrdma]
      Mar 30 13:21:45 klimt kernel: svc_rdma_sendto+0xf9/0x3ae [rpcrdma]
      Mar 30 13:21:45 klimt kernel: ? nfsd_destroy+0x51/0x51 [nfsd]
      Mar 30 13:21:45 klimt kernel: svc_send+0x105/0x1e3 [sunrpc]
      Mar 30 13:21:45 klimt kernel: nfsd+0xf2/0x149 [nfsd]
      Mar 30 13:21:45 klimt kernel: kthread+0xf6/0xfb
      Mar 30 13:21:45 klimt kernel: ? kthread_queue_delayed_work+0x74/0x74
      Mar 30 13:21:45 klimt kernel: ret_from_fork+0x3a/0x50
      Mar 30 13:21:45 klimt kernel: Modules linked in: ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue ib_umad ib_ipoib mlx4_ib sb_edac x86_pkg_temp_thermal iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel glue_helper crypto_simd cryptd pcspkr rpcrdma i2c_i801 rdma_ucm lpc_ich mfd_core ib_iser rdma_cm iw_cm ib_cm mei_me raid0 libiscsi mei sg scsi_transport_iscsi ioatdma wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter nfsd nfs_acl lockd auth_rpcgss grace sunrpc ip_tables xfs libcrc32c mlx4_en sd_mod sr_mod cdrom mlx4_core crc32c_intel igb nvme i2c_algo_bit ahci i2c_core libahci nvme_core dca libata t10_pi qedr dm_mirror dm_region_hash dm_log dm_mod dax qede qed crc8 ib_uverbs ib_core
      Mar 30 13:21:45 klimt kernel: CR2: ffff8887e6c279a8
      Mar 30 13:21:45 klimt kernel: ---[ end trace 87971d2ad3429424 ]---
      
      It's absolutely not safe to use resources pointed to by the @send_wr
      argument of ib_post_send() _after_ that function returns. Those
      resources are typically freed by the Send completion handler, which
      can run before ib_post_send() returns.
      
      Thus the trace points currently around ib_post_send() in the
      server's RPC/RDMA transport are a hazard, even when they are
      disabled. Rearrange them so that they touch the Work Request only
      _before_ ib_post_send() is invoked.
      
      Fixes: bd2abef3 ("svcrdma: Trace key RDMA API events")
      Fixes: 4201c746 ("svcrdma: Introduce svc_rdma_send_ctxt")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      e28b4fc6
  7. 17 4月, 2020 1 次提交
  8. 08 4月, 2020 3 次提交
  9. 04 4月, 2020 1 次提交
  10. 03 4月, 2020 1 次提交
    • J
      mm: mmap: add trace point of vm_unmapped_area · df529cab
      Jaewon Kim 提交于
      Even on 64 bit kernel, the mmap failure can happen for a 32 bit task.
      Virtual memory space shortage of a task on mmap is reported to userspace
      as -ENOMEM.  It can be confused as physical memory shortage of overall
      system.
      
      The vm_unmapped_area can be called to by some drivers or other kernel core
      system like filesystem.  In my platform, GPU driver calls to
      vm_unmapped_area and the driver returns -ENOMEM even in GPU side shortage.
      It can be hard to distinguish which code layer returns the -ENOMEM.
      
      Create mmap trace file and add trace point of vm_unmapped_area.
      
      i.e.)
      277.156599: vm_unmapped_area: addr=77e0d03000 err=0 total_vm=0x17014b flags=0x1 len=0x400000 lo=0x8000 hi=0x7878c27000 mask=0x0 ofs=0x1
      342.838740: vm_unmapped_area: addr=0 err=-12 total_vm=0xffb08 flags=0x0 len=0x100000 lo=0x40000000 hi=0xfffff000 mask=0x0 ofs=0x22
      
      [akpm@linux-foundation.org: prefix address printk with 0x, per Matthew]
      Signed-off-by: NJaewon Kim <jaewon31.kim@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Link: http://lkml.kernel.org/r/20200320055823.27089-3-jaewon31.kim@samsung.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      df529cab
  11. 27 3月, 2020 7 次提交
  12. 24 3月, 2020 3 次提交
  13. 22 3月, 2020 1 次提交
    • P
      rcu: Make rcu_barrier() account for offline no-CBs CPUs · 127e2981
      Paul E. McKenney 提交于
      Currently, rcu_barrier() ignores offline CPUs,  However, it is possible
      for an offline no-CBs CPU to have callbacks queued, and rcu_barrier()
      must wait for those callbacks.  This commit therefore makes rcu_barrier()
      directly invoke the rcu_barrier_func() with interrupts disabled for such
      CPUs.  This requires passing the CPU number into this function so that
      it can entrain the rcu_barrier() callback onto the correct CPU's callback
      list, given that the code must instead execute on the current CPU.
      
      While in the area, this commit fixes a bug where the first CPU's callback
      might have been invoked before rcu_segcblist_entrain() returned, which
      would also result in an early wakeup.
      
      Fixes: 5d6742b3 ("rcu/nocb: Use rcu_segcblist for no-CBs CPUs")
      Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
      [ paulmck: Apply optimization feedback from Boqun Feng. ]
      Cc: <stable@vger.kernel.org> # 5.5.x
      127e2981
  14. 17 3月, 2020 7 次提交
  15. 14 3月, 2020 1 次提交
    • D
      afs: Fix some tracing details · 4636cf18
      David Howells 提交于
      Fix a couple of tracelines to indicate the usage count after the atomic op,
      not the usage count before it to be consistent with other afs and rxrpc
      trace lines.
      
      Change the wording of the afs_call_trace_work trace ID label from "WORK" to
      "QUEUE" to reflect the fact that it's queueing work, not doing work.
      
      Fixes: 341f741f ("afs: Refcount the afs_call struct")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      4636cf18