1. 18 3月, 2020 1 次提交
  2. 13 3月, 2020 1 次提交
  3. 28 2月, 2020 1 次提交
  4. 21 2月, 2020 1 次提交
  5. 13 2月, 2020 1 次提交
  6. 26 1月, 2020 6 次提交
  7. 04 1月, 2020 3 次提交
  8. 20 11月, 2019 1 次提交
  9. 28 10月, 2019 2 次提交
  10. 05 10月, 2019 2 次提交
  11. 03 5月, 2019 1 次提交
  12. 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
  13. 04 4月, 2019 1 次提交
  14. 26 3月, 2019 1 次提交
  15. 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
  16. 20 12月, 2018 2 次提交
  17. 16 10月, 2018 1 次提交
  18. 27 9月, 2018 1 次提交
  19. 26 7月, 2018 1 次提交
  20. 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
  21. 26 6月, 2018 5 次提交
  22. 19 6月, 2018 2 次提交
  23. 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
  24. 01 6月, 2018 1 次提交
  25. 17 5月, 2018 1 次提交