1. 05 3月, 2019 1 次提交
  2. 20 2月, 2019 1 次提交
  3. 15 2月, 2019 1 次提交
  4. 05 2月, 2019 8 次提交
  5. 31 1月, 2019 1 次提交
    • B
      RDMA/srp: Increase max_segment_size · 0b5cb330
      Bart Van Assche 提交于
      The default behavior of the SCSI core is to set the block layer request
      queue parameter max_segment_size to 64 KB. That means that elements of
      scatterlists are limited to 64 KB. Since RDMA adapters support larger
      sizes, increase max_segment_size for the SRP initiator.
      
      Notes:
      - The SCSI max_segment_size parameter was introduced in kernel v5.0. See
        also commit 50c2e910 ("scsi: introduce a max_segment_size
        host_template parameters").
      - Some other block drivers already set max_segment_size to UINT_MAX,
        e.g. nbd and rbd.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      0b5cb330
  6. 30 1月, 2019 1 次提交
  7. 26 1月, 2019 2 次提交
    • M
      infiniband: remove unneeded header search paths · ed4cdf4a
      Masahiro Yamada 提交于
      The included headers are located in include/target/. I was able to
      build these drivers without the extra header search paths.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      ed4cdf4a
    • F
      IB/ipoib: Fix for use-after-free in ipoib_cm_tx_start · 6ab4aba0
      Feras Daoud 提交于
      The following BUG was reported by kasan:
      
       BUG: KASAN: use-after-free in ipoib_cm_tx_start+0x430/0x1390 [ib_ipoib]
       Read of size 80 at addr ffff88034c30bcd0 by task kworker/u16:1/24020
      
       Workqueue: ipoib_wq ipoib_cm_tx_start [ib_ipoib]
       Call Trace:
        dump_stack+0x9a/0xeb
        print_address_description+0xe3/0x2e0
        kasan_report+0x18a/0x2e0
        ? ipoib_cm_tx_start+0x430/0x1390 [ib_ipoib]
        memcpy+0x1f/0x50
        ipoib_cm_tx_start+0x430/0x1390 [ib_ipoib]
        ? kvm_clock_read+0x1f/0x30
        ? ipoib_cm_skb_reap+0x610/0x610 [ib_ipoib]
        ? __lock_is_held+0xc2/0x170
        ? process_one_work+0x880/0x1960
        ? process_one_work+0x912/0x1960
        process_one_work+0x912/0x1960
        ? wq_pool_ids_show+0x310/0x310
        ? lock_acquire+0x145/0x440
        worker_thread+0x87/0xbb0
        ? process_one_work+0x1960/0x1960
        kthread+0x314/0x3d0
        ? kthread_create_worker_on_cpu+0xc0/0xc0
        ret_from_fork+0x3a/0x50
      
       Allocated by task 0:
        kasan_kmalloc+0xa0/0xd0
        kmem_cache_alloc_trace+0x168/0x3e0
        path_rec_create+0xa2/0x1f0 [ib_ipoib]
        ipoib_start_xmit+0xa98/0x19e0 [ib_ipoib]
        dev_hard_start_xmit+0x159/0x8d0
        sch_direct_xmit+0x226/0xb40
        __dev_queue_xmit+0x1d63/0x2950
        neigh_update+0x889/0x1770
        arp_process+0xc47/0x21f0
        arp_rcv+0x462/0x760
        __netif_receive_skb_core+0x1546/0x2da0
        netif_receive_skb_internal+0xf2/0x590
        napi_gro_receive+0x28e/0x390
        ipoib_ib_handle_rx_wc_rss+0x873/0x1b60 [ib_ipoib]
        ipoib_rx_poll_rss+0x17d/0x320 [ib_ipoib]
        net_rx_action+0x427/0xe30
        __do_softirq+0x28e/0xc42
      
       Freed by task 26680:
        __kasan_slab_free+0x11d/0x160
        kfree+0xf5/0x360
        ipoib_flush_paths+0x532/0x9d0 [ib_ipoib]
        ipoib_set_mode_rss+0x1ad/0x560 [ib_ipoib]
        set_mode+0xc8/0x150 [ib_ipoib]
        kernfs_fop_write+0x279/0x440
        __vfs_write+0xd8/0x5c0
        vfs_write+0x15e/0x470
        ksys_write+0xb8/0x180
        do_syscall_64+0x9b/0x420
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       The buggy address belongs to the object at ffff88034c30bcc8
                      which belongs to the cache kmalloc-512 of size 512
       The buggy address is located 8 bytes inside of
                      512-byte region [ffff88034c30bcc8, ffff88034c30bec8)
       The buggy address belongs to the page:
      
      The following race between change mode and xmit flow is the reason for
      this use-after-free:
      
      Change mode     Send packet 1 to GID XX      Send packet 2 to GID XX
           |                    |                             |
         start                  |                             |
           |                    |                             |
           |                    |                             |
           |         Create new path for GID XX               |
           |           and update neigh path                  |
           |                    |                             |
           |                    |                             |
           |                    |                             |
       flush_paths              |                             |
                                |                             |
                     queue_work(cm.start_task)                |
                                |                 Path for GID XX not found
                                |                      create new path
                                |
                                |
                     start_task runs with old
                          released path
      
      There is no locking to protect the lifetime of the path through the
      ipoib_cm_tx struct, so delete it entirely and always use the newly looked
      up path under the priv->lock.
      
      Fixes: 546481c2 ("IB/ipoib: Fix memory corruption in ipoib cm mode connect flow")
      Signed-off-by: NFeras Daoud <ferasda@mellanox.com>
      Reviewed-by: NErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      6ab4aba0
  8. 25 1月, 2019 1 次提交
  9. 19 1月, 2019 1 次提交
  10. 09 1月, 2019 1 次提交
    • G
      IB/srp: Use struct_size() in kzalloc() · 7a7b0fea
      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 = kzalloc(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 = kzalloc(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>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      7a7b0fea
  11. 03 1月, 2019 1 次提交
  12. 23 12月, 2018 1 次提交
  13. 20 12月, 2018 17 次提交
  14. 19 12月, 2018 1 次提交
  15. 12 12月, 2018 1 次提交
  16. 07 12月, 2018 1 次提交