1. 05 10月, 2019 1 次提交
  2. 03 5月, 2019 1 次提交
  3. 09 4月, 2019 1 次提交
    • L
      RDMA/cm: Move debug counters to be under relevant IB device · c87e65cf
      Leon Romanovsky 提交于
      The sysfs layout is created by CM incorrectly presented RDMA devices with
      InfiniBand link layer. Layout of such devices represents device tree of
      connections. By moving CM statistics to be under relevant port of IB
      device, we will fix the following issues:
      
       * Symlink name - It used device name instead of specific identifier.
       * Target location - It was supposed to point to PCI-ID/infiniband_cm/
         instead of PCI-ID/infiniband/
       * Target name - It created extra device file under already existing
         device folder, e.g. mlx5_0/mlx5_0
       * Crash during boot with RDMA persistent naming patches.
      
       sysfs: cannot create duplicate filename '/class/infiniband_cm/mlx5_0'
       CPU: 29 PID: 433 Comm: modprobe Not tainted 5.0.0-rc5+ #178
       Call Trace:
        dump_stack+0xcc/0x180
        sysfs_warn_dup.cold.3+0x17/0x2d
        sysfs_do_create_link_sd.isra.2+0xd0/0xf0
        device_add+0x7cb/0x1450
        device_create_groups_vargs+0x1ae/0x220
        device_create+0x93/0xc0
        cm_add_one+0x38f/0xf60 [ib_cm]
        add_client_context+0x167/0x210 [ib_core]
        enable_device_and_get+0x230/0x3f0 [ib_core]
        ib_register_device+0x823/0xbf0 [ib_core]
        __mlx5_ib_add+0x45/0x150 [mlx5_ib]
        mlx5_ib_add+0x1b3/0x5e0 [mlx5_ib]
        mlx5_add_device+0x130/0x3a0 [mlx5_core]
        mlx5_register_interface+0x1a9/0x270 [mlx5_core]
        do_one_initcall+0x14f/0x5de
        do_init_module+0x247/0x7c0
        load_module+0x4c2f/0x60d0
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      After this change:
      [leonro@server ~]$ ls -al /sys/class/infiniband/ibp0s12f0/ports/1/
      drwxr-xr-x  2 root root    0 Mar 11 11:17 cm_rx_duplicates
      drwxr-xr-x  2 root root    0 Mar 11 11:17 cm_rx_msgs
      drwxr-xr-x  2 root root    0 Mar 11 11:17 cm_tx_msgs
      drwxr-xr-x  2 root root    0 Mar 11 11:17 cm_tx_retries
      
      Fixes: 110cf374 ("infiniband: make cm_device use a struct device and not a kobject.")
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      c87e65cf
  4. 04 4月, 2019 1 次提交
  5. 26 3月, 2019 1 次提交
  6. 08 1月, 2019 1 次提交
    • G
      IB/cm: Use struct_size() in kmalloc() · b5c61b96
      Gustavo A. R. Silva 提交于
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct foo {
          int stuff;
          void *entry[];
      };
      
      instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
      
      This code was detected with the help of Coccinelle.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      b5c61b96
  7. 20 12月, 2018 2 次提交
  8. 16 10月, 2018 1 次提交
  9. 27 9月, 2018 1 次提交
  10. 26 7月, 2018 1 次提交
  11. 10 7月, 2018 1 次提交
    • H
      IB/cm: Remove unused and erroneous msg sequence encoding · 87a37ce9
      Håkon Bugge 提交于
      In cm_form_tid(), a two bit message sequence number is OR'ed into bit
      31-30 of the lower TID value.
      
      After commit f06d2653 ("IB/cm: Randomize starting comm ID"), the
      local_id is XOR'ed with a 32-bit random value. Hence, bit 31-30 in the
      lower TID now has an arbitrarily value and it makes no sense to OR in
      the message sequence number.
      
      Adding to that, the evolution in use of IDR routines in cm_alloc_id()
      has always had the possibility of returning a value with bit 30 set.
      
      In addition, said bits are never checked.
      
      Hence, remove the encoding and the corresponding enum.
      Signed-off-by: NHåkon Bugge <haakon.bugge@oracle.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      87a37ce9
  12. 26 6月, 2018 5 次提交
  13. 19 6月, 2018 2 次提交
  14. 07 6月, 2018 1 次提交
    • K
      treewide: Use struct_size() for kmalloc()-family · acafe7e3
      Kees Cook 提交于
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct foo {
          int stuff;
          void *entry[];
      };
      
      instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
      
      This patch makes the changes for kmalloc()-family (and kvmalloc()-family)
      uses. It was done via automatic conversion with manual review for the
      "CHECKME" non-standard cases noted below, using the following Coccinelle
      script:
      
      // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len *
      //                      sizeof *pkey_cache->table, GFP_KERNEL);
      @@
      identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
      expression GFP;
      identifier VAR, ELEMENT;
      expression COUNT;
      @@
      
      - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP)
      + alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
      
      // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL);
      @@
      identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
      expression GFP;
      identifier VAR, ELEMENT;
      expression COUNT;
      @@
      
      - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP)
      + alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
      
      // Same pattern, but can't trivially locate the trailing element name,
      // or variable name.
      @@
      identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
      expression GFP;
      expression SOMETHING, COUNT, ELEMENT;
      @@
      
      - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP)
      + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP)
      Signed-off-by: NKees Cook <keescook@chromium.org>
      acafe7e3
  15. 01 6月, 2018 1 次提交
  16. 17 5月, 2018 3 次提交
  17. 28 3月, 2018 1 次提交
    • P
      IB/cm: Block processing alternate path handling RoCE Rx cm messages · 97c45c2c
      Parav Pandit 提交于
      Due to below reasons, it is better to not support alternate path receive
      messages for RoCE in near term.
      
      1. Alternate path for RoCE is not supported at rdmacm layer.
      2. It is not supported in uverbs/core layer for RoCE.
      3. Alternate path for IPv6 for link local address cannot resolve route
      determinstically without a valid incoming interface id whose usecase
      make sense only with dual port mode.
      4. init_av_from_path while processing LAP messages for IB and RoCE can
      lead to adding duplicate entry of AV into the port list, leads to list
      corruption.
      5. rdma-core userspace a well known userspace implementation has removed
      support of libucm which use ucm.ko module, which is the only module that
      can trigger alternate path related messages.
      6. ucm kernel module is requested to be removed from the IB core in
      patch [1].
      
      [1] https://patchwork.kernel.org/patch/10268503/Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      97c45c2c
  18. 24 3月, 2018 1 次提交
    • P
      IB/cma: Resolve route only while receiving CM requests · 114cc9c4
      Parav Pandit 提交于
      Currently CM request for RoCE follows following flow.
      rdma_create_id()
      rdma_resolve_addr()
      rdma_resolve_route()
      For RC QPs:
      rdma_connect()
      ->cma_connect_ib()
        ->ib_send_cm_req()
          ->cm_init_av_by_path()
            ->ib_init_ah_attr_from_path()
      For UD QPs:
      rdma_connect()
      ->cma_resolve_ib_udp()
        ->ib_send_cm_sidr_req()
          ->cm_init_av_by_path()
            ->ib_init_ah_attr_from_path()
      
      In both the flows, route is already resolved before sending CM requests.
      Therefore, code is refactored to avoid resolving route second time in
      ib_cm layer.
      ib_init_ah_attr_from_path() is extended to resolve route when it is not
      yet resolved for RoCE link layer. This is achieved by caller setting
      route_resolved field in path record whenever it has route already
      resolved.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      114cc9c4
  19. 16 3月, 2018 2 次提交
  20. 29 1月, 2018 2 次提交
  21. 19 12月, 2017 8 次提交
  22. 12 12月, 2017 1 次提交
  23. 26 10月, 2017 1 次提交
    • P
      IB/cm: Fix memory corruption in handling CM request · 5a3dc323
      Parav Pandit 提交于
      In recent code, two path record entries are alwasy cleared while
      allocated could be either one or two path record entries.
      This leads to zero out of unallocated memory.
      
      This fix initializes alternative path record only when alternative path
      is set.
      
      While we are at it, path record allocation doesn't check for OPA
      alternative path, but rest of the code checks for OPA alternative path.
      Path record allocation code doesn't check for OPA alternative LID.
      This can further lead to memory corruption when only one path record is
      allocated, but there is actually alternative OPA path record present in CM
      request.
      
      Cc: <stable@vger.kernel.org> # v4.12+
      Fixes: 9fdca4da ("IB/SA: Split struct sa_path_rec based on IB and ROCE specific fields")
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      5a3dc323