1. 25 8月, 2020 1 次提交
  2. 14 7月, 2020 7 次提交
  3. 12 6月, 2020 1 次提交
  4. 18 5月, 2020 7 次提交
  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 1 次提交
    • 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. 27 3月, 2020 6 次提交
  8. 17 3月, 2020 4 次提交
    • C
      svcrdma: Avoid DMA mapping small RPC Replies · 0dabe948
      Chuck Lever 提交于
      On some platforms, DMA mapping part of a page is more costly than
      copying bytes. Indeed, not involving the I/O MMU can help the
      RPC/RDMA transport scale better for tiny I/Os across more RDMA
      devices. This is because interaction with the I/O MMU is eliminated
      for each of these small I/Os. Without the explicit unmapping, the
      NIC no longer needs to do a costly internal TLB shoot down for
      buffers that are just a handful of bytes.
      
      Since pull-up is now a more a frequent operation, I've introduced a
      trace point in the pull-up path. It can be used for debugging or
      user-space tools that count pull-up frequency.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      0dabe948
    • C
      svcrdma: Rename svcrdma_encode trace points in send routines · a406c563
      Chuck Lever 提交于
      These trace points are misnamed:
      
      	trace_svcrdma_encode_wseg
      	trace_svcrdma_encode_write
      	trace_svcrdma_encode_reply
      	trace_svcrdma_encode_rseg
      	trace_svcrdma_encode_read
      	trace_svcrdma_encode_pzr
      
      Because they actually trace posting on the Send Queue. Let's rename
      them so that I can add trace points in the chunk list encoders that
      actually do trace chunk list encoding events.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      a406c563
    • C
      svcrdma: Use struct xdr_stream to decode ingress transport headers · e604aad2
      Chuck Lever 提交于
      The logic that checks incoming network headers has to be scrupulous.
      
      De-duplicate: replace open-coded buffer overflow checks with the use
      of xdr_stream helpers that are used most everywhere else XDR
      decoding is done.
      
      One minor change to the sanity checks: instead of checking the
      length of individual segments, cap the length of the whole chunk
      to be sure it can fit in the set of pages available in rq_pages.
      This should be a better test of whether the server can handle the
      chunks in each request.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      e604aad2
    • C
      svcrdma: Remove svcrdma_cm_event() trace point · 2426ddfd
      Chuck Lever 提交于
      Clean up. This trace point is no longer needed because the RDMA/core
      CMA code has an equivalent trace point that was added by commit
      ed999f82 ("RDMA/cma: Add trace points in RDMA Connection
      Manager").
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      2426ddfd
  9. 15 1月, 2020 1 次提交
  10. 27 11月, 2019 1 次提交
    • P
      ftrace: Rework event_create_dir() · 04ae87a5
      Peter Zijlstra 提交于
      Rework event_create_dir() to use an array of static data instead of
      function pointers where possible.
      
      The problem is that it would call the function pointer on module load
      before parse_args(), possibly even before jump_labels were initialized.
      Luckily the generated functions don't use jump_labels but it still seems
      fragile. It also gets in the way of changing when we make the module map
      executable.
      
      The generated function are basically calling trace_define_field() with a
      bunch of static arguments. So instead of a function, capture these
      arguments in a static array, avoiding the function call.
      
      Now there are a number of cases where the fields are dynamic (syscall
      arguments, kprobes and uprobes), in which case a static array does not
      work, for these we preserve the function call. Luckily all these cases
      are not related to modules and so we can retain the function call for
      them.
      
      Also fix up all broken tracepoint definitions that now generate a
      compile error.
      Tested-by: NAlexei Starovoitov <ast@kernel.org>
      Tested-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20191111132458.342979914@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      04ae87a5
  11. 24 10月, 2019 7 次提交
  12. 09 10月, 2019 1 次提交
  13. 21 8月, 2019 2 次提交