1. 07 Jan, 2020 8 commits
    • Yixing Liu's avatar
      RDMA/hns: Remove redundant print information · 0c53426c
      Yixing Liu authored
      There are already necessary prints in outer function, prints in
      hns_roce_function_clear() may confuse users. So these prints is removed.
      
      Link: https://lore.kernel.org/r/1578313276-29080-6-git-send-email-liweihang@huawei.comSigned-off-by: default avatarYixing Liu <liuyixing1@huawei.com>
      Signed-off-by: default avatarWeihang Li <liweihang@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      0c53426c
    • Lijun Ou's avatar
      RDMA/hns: Delete unnessary parameters in hns_roce_v2_qp_modify() · 032b0574
      Lijun Ou authored
      Current state and new state of qp won't be configured when modifying qp,
      so these two redundant parameters should be removed.
      
      Link: https://lore.kernel.org/r/1578313276-29080-5-git-send-email-liweihang@huawei.comSigned-off-by: default avatarLijun Ou <oulijun@huawei.com>
      Signed-off-by: default avatarWeihang Li <liweihang@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      032b0574
    • Lijun Ou's avatar
      RDMA/hns: Update the value of qp type · 5e049a5d
      Lijun Ou authored
      The values used to represent service type of RC and UD should be
      interchanged according to design of hardware. And it's better to define
      these types in enumeration than macros.
      
      Link: https://lore.kernel.org/r/1578313276-29080-4-git-send-email-liweihang@huawei.comSigned-off-by: default avatarLijun Ou <oulijun@huawei.com>
      Signed-off-by: default avatarWeihang Li <liweihang@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      5e049a5d
    • Lijun Ou's avatar
      RDMA/hns: Remove unused function hns_roce_init_eq_table() · 58e4fc11
      Lijun Ou authored
      hns_roce_init_eq_table() is an unused function that only retains its
      declaration in driver.
      
      Link: https://lore.kernel.org/r/1578313276-29080-3-git-send-email-liweihang@huawei.comSigned-off-by: default avatarLijun Ou <oulijun@huawei.com>
      Signed-off-by: default avatarWeihang Li <liweihang@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      58e4fc11
    • Wenpeng Liang's avatar
      RDMA/hns: Avoid printing address of mtt page · eca44507
      Wenpeng Liang authored
      Address of a page shouldn't be printed in case of security issues.
      
      Link: https://lore.kernel.org/r/1578313276-29080-2-git-send-email-liweihang@huawei.comSigned-off-by: default avatarWenpeng Liang <liangwenpeng@huawei.com>
      Signed-off-by: default avatarWeihang Li <liweihang@huawei.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      eca44507
    • Chuck Lever's avatar
      RDMA/core: Add trace points to follow MR allocation · 622db5b6
      Chuck Lever authored
      Track the lifetime of ib_mr objects. Here's sample output from a test run
      with NFS/RDMA:
      
                 <...>-361   [009] 79238.772782: mr_alloc:             pd.id=3 mr.id=11 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772812: mr_alloc:             pd.id=3 mr.id=12 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772839: mr_alloc:             pd.id=3 mr.id=13 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772866: mr_alloc:             pd.id=3 mr.id=14 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772893: mr_alloc:             pd.id=3 mr.id=15 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772921: mr_alloc:             pd.id=3 mr.id=16 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772947: mr_alloc:             pd.id=3 mr.id=17 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.772974: mr_alloc:             pd.id=3 mr.id=18 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.773001: mr_alloc:             pd.id=3 mr.id=19 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.773028: mr_alloc:             pd.id=3 mr.id=20 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79238.773055: mr_alloc:             pd.id=3 mr.id=21 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.270942: mr_alloc:             pd.id=3 mr.id=22 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.270975: mr_alloc:             pd.id=3 mr.id=23 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271007: mr_alloc:             pd.id=3 mr.id=24 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271036: mr_alloc:             pd.id=3 mr.id=25 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271067: mr_alloc:             pd.id=3 mr.id=26 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271095: mr_alloc:             pd.id=3 mr.id=27 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271121: mr_alloc:             pd.id=3 mr.id=28 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271153: mr_alloc:             pd.id=3 mr.id=29 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271181: mr_alloc:             pd.id=3 mr.id=30 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271208: mr_alloc:             pd.id=3 mr.id=31 type=MEM_REG max_num_sg=30 rc=0
                 <...>-361   [009] 79240.271236: mr_alloc:             pd.id=3 mr.id=32 type=MEM_REG max_num_sg=30 rc=0
                 <...>-4351  [001] 79242.299400: mr_dereg:             mr.id=32
                 <...>-4351  [001] 79242.299467: mr_dereg:             mr.id=31
                 <...>-4351  [001] 79242.299554: mr_dereg:             mr.id=30
                 <...>-4351  [001] 79242.299615: mr_dereg:             mr.id=29
                 <...>-4351  [001] 79242.299684: mr_dereg:             mr.id=28
                 <...>-4351  [001] 79242.299748: mr_dereg:             mr.id=27
                 <...>-4351  [001] 79242.299812: mr_dereg:             mr.id=26
                 <...>-4351  [001] 79242.299874: mr_dereg:             mr.id=25
                 <...>-4351  [001] 79242.299944: mr_dereg:             mr.id=24
                 <...>-4351  [001] 79242.300009: mr_dereg:             mr.id=23
                 <...>-4351  [001] 79242.300190: mr_dereg:             mr.id=22
                 <...>-4351  [001] 79242.300263: mr_dereg:             mr.id=21
                 <...>-4351  [001] 79242.300326: mr_dereg:             mr.id=20
                 <...>-4351  [001] 79242.300388: mr_dereg:             mr.id=19
                 <...>-4351  [001] 79242.300450: mr_dereg:             mr.id=18
                 <...>-4351  [001] 79242.300516: mr_dereg:             mr.id=17
                 <...>-4351  [001] 79242.300629: mr_dereg:             mr.id=16
                 <...>-4351  [001] 79242.300718: mr_dereg:             mr.id=15
                 <...>-4351  [001] 79242.300784: mr_dereg:             mr.id=14
                 <...>-4351  [001] 79242.300879: mr_dereg:             mr.id=13
                 <...>-4351  [001] 79242.300945: mr_dereg:             mr.id=12
                 <...>-4351  [001] 79242.301012: mr_dereg:             mr.id=11
      
      Some features of the output:
      - The lifetime and owner PD of each MR is clearly visible.
      - The type of MR is captured, as is the SGE array size.
      - Failing MR allocation can be recorded.
      
      Link: https://lore.kernel.org/r/20191218201820.30584.34636.stgit@manet.1015granger.netSigned-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      622db5b6
    • Chuck Lever's avatar
      RDMA/core: Trace points for diagnosing completion queue issues · 3e5901cb
      Chuck Lever authored
      Sample trace events:
      
         kworker/u29:0-300   [007]   120.042217: cq_alloc:             cq.id=4 nr_cqe=161 comp_vector=2 poll_ctx=WORKQUEUE
                <idle>-0     [002]   120.056292: cq_schedule:          cq.id=4
          kworker/2:1H-482   [002]   120.056402: cq_process:           cq.id=4 wake-up took 109 [us] from interrupt
          kworker/2:1H-482   [002]   120.056407: cq_poll:              cq.id=4 requested 16, returned 1
                <idle>-0     [002]   120.067503: cq_schedule:          cq.id=4
          kworker/2:1H-482   [002]   120.067537: cq_process:           cq.id=4 wake-up took 34 [us] from interrupt
          kworker/2:1H-482   [002]   120.067541: cq_poll:              cq.id=4 requested 16, returned 1
                <idle>-0     [002]   120.067657: cq_schedule:          cq.id=4
          kworker/2:1H-482   [002]   120.067672: cq_process:           cq.id=4 wake-up took 15 [us] from interrupt
          kworker/2:1H-482   [002]   120.067674: cq_poll:              cq.id=4 requested 16, returned 1
      
       ...
      
               systemd-1     [002]   122.392653: cq_schedule:          cq.id=4
          kworker/2:1H-482   [002]   122.392688: cq_process:           cq.id=4 wake-up took 35 [us] from interrupt
          kworker/2:1H-482   [002]   122.392693: cq_poll:              cq.id=4 requested 16, returned 16
          kworker/2:1H-482   [002]   122.392836: cq_poll:              cq.id=4 requested 16, returned 16
          kworker/2:1H-482   [002]   122.392970: cq_poll:              cq.id=4 requested 16, returned 16
          kworker/2:1H-482   [002]   122.393083: cq_poll:              cq.id=4 requested 16, returned 16
          kworker/2:1H-482   [002]   122.393195: cq_poll:              cq.id=4 requested 16, returned 3
      
      Several features to note in this output:
       - The WCE count and context type are reported at allocation time
       - The CPU and kworker for each CQ is evident
       - The CQ's restracker ID is tagged on each trace event
       - CQ poll scheduling latency is measured
       - Details about how often single completions occur versus multiple
         completions are evident
       - The cost of the ULP's completion handler is recorded
      
      Link: https://lore.kernel.org/r/20191218201815.30584.3481.stgit@manet.1015granger.netSigned-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      3e5901cb
    • Chuck Lever's avatar
      RDMA/cma: Add trace points in RDMA Connection Manager · ed999f82
      Chuck Lever authored
      Record state transitions as each connection is established. The IP address
      of both peers and the Type of Service is reported. These trace points are
      not in performance hot paths.
      
      Also, record each cm_event_handler call to ULPs. This eliminates the need
      for each ULP to add its own similar trace point in its CM event handler
      function.
      
      These new trace points appear in a new trace subsystem called "rdma_cma".
      
      Sample events:
      
                 <...>-220   [004]   121.430733: cm_id_create:         cm.id=0
                 <...>-472   [003]   121.430991: cm_event_handler:     cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0)
                 <...>-472   [003]   121.430995: cm_event_done:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0
                 <...>-472   [003]   121.431172: cm_event_handler:     cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0)
                 <...>-472   [003]   121.431174: cm_event_done:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0
                 <...>-220   [004]   121.433480: cm_qp_create:         cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0
                 <...>-220   [004]   121.433577: cm_send_req:          cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521
           kworker/1:2-973   [001]   121.436190: cm_send_mra:          cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0
           kworker/1:2-973   [001]   121.436340: cm_send_rtu:          cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0
           kworker/1:2-973   [001]   121.436359: cm_event_handler:     cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0)
           kworker/1:2-973   [001]   121.436365: cm_event_done:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0
                 <...>-1975  [005]   123.161954: cm_disconnect:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0
                 <...>-1975  [005]   123.161974: cm_sent_dreq:         cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0
                 <...>-220   [004]   123.162102: cm_disconnect:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0
           kworker/0:1-13    [000]   123.162391: cm_event_handler:     cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0)
           kworker/0:1-13    [000]   123.162393: cm_event_done:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0
                 <...>-220   [004]   123.164456: cm_qp_destroy:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521
                 <...>-220   [004]   123.165290: cm_id_destroy:        cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0
      
      Some features to note:
      - restracker ID of the rdma_cm_id is tagged on each trace event
      - The source and destination IP addresses and TOS are reported
      - CM event upcalls are shown with decoded event and status
      - CM state transitions are reported
      - rdma_cm_id lifetime events are captured
      - The latency of ULP CM event handlers is reported
      - Lifetime events of associated QPs are reported
      - Device removal and insertion is reported
      
      This patch is based on previous work by:
      
      Saeed Mahameed <saeedm@mellanox.com>
      Mukesh Kacker <mukesh.kacker@oracle.com>
      Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com>
      Aron Silverton <aron.silverton@oracle.com>
      Avinash Repaka <avinash.repaka@oracle.com>
      Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
      
      Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.netSigned-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      ed999f82
  2. 04 Jan, 2020 2 commits
  3. 03 Jan, 2020 22 commits
  4. 29 Dec, 2019 5 commits
  5. 28 Dec, 2019 3 commits
    • Olof Johansson's avatar
      riscv: export flush_icache_all to modules · 1833e327
      Olof Johansson authored
      This is needed by LKDTM (crash dump test module), it calls
      flush_icache_range(), which on RISC-V turns into flush_icache_all(). On
      other architectures, the actual implementation is exported, so follow
      that precedence and export it here too.
      
      Fixes build of CONFIG_LKDTM that fails with:
      ERROR: "flush_icache_all" [drivers/misc/lkdtm/lkdtm.ko] undefined!
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      1833e327
    • David Abdurachmanov's avatar
      riscv: reject invalid syscalls below -1 · 556f47ac
      David Abdurachmanov authored
      Running "stress-ng --enosys 4 -t 20 -v" showed a large number of kernel oops
      with "Unable to handle kernel paging request at virtual address" message. This
      happens when enosys stressor starts testing random non-valid syscalls.
      
      I forgot to redirect any syscall below -1 to sys_ni_syscall.
      
      With the patch kernel oops messages are gone while running stress-ng enosys
      stressor.
      Signed-off-by: default avatarDavid Abdurachmanov <david.abdurachmanov@sifive.com>
      Fixes: 5340627e ("riscv: add support for SECCOMP and SECCOMP_FILTER")
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      556f47ac
    • Luc Van Oostenryck's avatar
      riscv: fix compile failure with EXPORT_SYMBOL() & !MMU · 4d47ce15
      Luc Van Oostenryck authored
      When support for !MMU was added, the declaration of
      __asm_copy_to_user() & __asm_copy_from_user() were #ifdefed
      out hence their EXPORT_SYMBOL() give an error message like:
        .../riscv_ksyms.c:13:15: error: '__asm_copy_to_user' undeclared here
        .../riscv_ksyms.c:14:15: error: '__asm_copy_from_user' undeclared here
      
      Since these symbols are not defined with !MMU it's wrong to export them.
      Same for __clear_user() (even though this one is also declared in
      include/asm-generic/uaccess.h and thus doesn't give an error message).
      
      Fix this by doing the EXPORT_SYMBOL() directly where these symbols
      are defined: inside lib/uaccess.S itself.
      
      Fixes: 6bd33e1e ("riscv: fix compile failure with EXPORT_SYMBOL() & !MMU")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      4d47ce15