1. 23 11月, 2019 1 次提交
  2. 22 8月, 2019 1 次提交
  3. 12 8月, 2019 1 次提交
  4. 01 8月, 2019 2 次提交
    • J
      RDMA/devices: Remove the lock around remove_client_context · 9cd58817
      Jason Gunthorpe 提交于
      Due to the complexity of client->remove() callbacks it is desirable to not
      hold any locks while calling them. Remove the last one by tracking only
      the highest client ID and running backwards from there over the xarray.
      
      Since the only purpose of that lock was to protect the linked list, we can
      drop the lock.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081841.32345-3-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>
      9cd58817
    • J
      RDMA/devices: Do not deadlock during client removal · 621e55ff
      Jason Gunthorpe 提交于
      lockdep reports:
      
         WARNING: possible circular locking dependency detected
      
         modprobe/302 is trying to acquire lock:
         0000000007c8919c ((wq_completion)ib_cm){+.+.}, at: flush_workqueue+0xdf/0x990
      
         but task is already holding lock:
         000000002d3d2ca9 (&device->client_data_rwsem){++++}, at: remove_client_context+0x79/0xd0 [ib_core]
      
         which lock already depends on the new lock.
      
         the existing dependency chain (in reverse order) is:
      
         -> #2 (&device->client_data_rwsem){++++}:
                down_read+0x3f/0x160
                ib_get_net_dev_by_params+0xd5/0x200 [ib_core]
                cma_ib_req_handler+0x5f6/0x2090 [rdma_cm]
                cm_process_work+0x29/0x110 [ib_cm]
                cm_req_handler+0x10f5/0x1c00 [ib_cm]
                cm_work_handler+0x54c/0x311d [ib_cm]
                process_one_work+0x4aa/0xa30
                worker_thread+0x62/0x5b0
                kthread+0x1ca/0x1f0
                ret_from_fork+0x24/0x30
      
         -> #1 ((work_completion)(&(&work->work)->work)){+.+.}:
                process_one_work+0x45f/0xa30
                worker_thread+0x62/0x5b0
                kthread+0x1ca/0x1f0
                ret_from_fork+0x24/0x30
      
         -> #0 ((wq_completion)ib_cm){+.+.}:
                lock_acquire+0xc8/0x1d0
                flush_workqueue+0x102/0x990
                cm_remove_one+0x30e/0x3c0 [ib_cm]
                remove_client_context+0x94/0xd0 [ib_core]
                disable_device+0x10a/0x1f0 [ib_core]
                __ib_unregister_device+0x5a/0xe0 [ib_core]
                ib_unregister_device+0x21/0x30 [ib_core]
                mlx5_ib_stage_ib_reg_cleanup+0x9/0x10 [mlx5_ib]
                __mlx5_ib_remove+0x3d/0x70 [mlx5_ib]
                mlx5_ib_remove+0x12e/0x140 [mlx5_ib]
                mlx5_remove_device+0x144/0x150 [mlx5_core]
                mlx5_unregister_interface+0x3f/0xf0 [mlx5_core]
                mlx5_ib_cleanup+0x10/0x3a [mlx5_ib]
                __x64_sys_delete_module+0x227/0x350
                do_syscall_64+0xc3/0x6a4
                entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Which is due to the read side of the client_data_rwsem being obtained
      recursively through a work queue flush during cm client removal.
      
      The lock is being held across the remove in remove_client_context() so
      that the function is a fence, once it returns the client is removed. This
      is required so that the two callers do not proceed with destruction until
      the client completes removal.
      
      Instead of using client_data_rwsem use the existing device unregistration
      refcount and add a similar client unregistration (client->uses) refcount.
      
      This will fence the two unregistration paths without holding any locks.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 921eab11 ("RDMA/devices: Re-organize device.c locking")
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081841.32345-2-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>
      621e55ff
  5. 26 7月, 2019 1 次提交
  6. 25 7月, 2019 1 次提交
  7. 09 7月, 2019 1 次提交
  8. 05 7月, 2019 3 次提交
  9. 24 6月, 2019 2 次提交
  10. 19 6月, 2019 2 次提交
  11. 17 6月, 2019 1 次提交
  12. 14 6月, 2019 1 次提交
  13. 12 6月, 2019 1 次提交
  14. 11 6月, 2019 3 次提交
  15. 28 5月, 2019 1 次提交
    • K
      RDMA/core: Fix panic when port_data isn't initialized · 46bdf370
      Kamal Heib 提交于
      This happens if assign_name() returns failure when called from
      ib_register_device(), that will lead to the following panic in every time
      that someone touches the port_data's data members.
      
       BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0
       PGD 0 P4D 0
       Oops: 0002 [#1] SMP PTI
       CPU: 19 PID: 1994 Comm: systemd-udevd Not tainted 5.1.0-rc5+ #1
       Hardware name: HP ProLiant DL360p Gen8, BIOS P71 12/20/2013
       RIP: 0010:_raw_spin_lock_irqsave+0x1e/0x40
       Code: 85 ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 9c 58 66 66 90
       66 90 48 89 c3 fa 66 66 90 66 66 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 0f
       94 c2 84 d2 74 05 48 89 d8 5b c3 89 c6 e8 b4 85 8a
       RSP: 0018:ffffa8d7079a7c08 EFLAGS: 00010046
       RAX: 0000000000000000 RBX: 0000000000000202 RCX: ffffa8d7079a7bf8
       RDX: 0000000000000001 RSI: ffff93607c990000 RDI: 00000000000000c0
       RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffc08c4dd8
       R10: 0000000000000000 R11: 0000000000000001 R12: 00000000000000c0
       R13: ffff93607c990000 R14: ffffffffc05a9740 R15: ffffa8d7079a7e98
       FS:  00007f1c6ee438c0(0000) GS:ffff93609f6c0000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00000000000000c0 CR3: 0000000819fca002 CR4: 00000000000606e0
       Call Trace:
        free_netdevs+0x4d/0xe0 [ib_core]
        ib_dealloc_device+0x51/0xb0 [ib_core]
        __mlx5_ib_add+0x5e/0x70 [mlx5_ib]
        mlx5_add_device+0x57/0xe0 [mlx5_core]
        mlx5_register_interface+0x85/0xc0 [mlx5_core]
        ? 0xffffffffc0474000
        do_one_initcall+0x4e/0x1d4
        ? _cond_resched+0x15/0x30
        ? kmem_cache_alloc_trace+0x15f/0x1c0
        do_init_module+0x5a/0x218
        load_module+0x186b/0x1e40
        ? m_show+0x1c0/0x1c0
        __do_sys_finit_module+0x94/0xe0
        do_syscall_64+0x5b/0x180
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 8ceb1357 ("RDMA/device: Consolidate ib_device per_port data into one place")
      Signed-off-by: NKamal Heib <kamalheib1@gmail.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      46bdf370
  16. 22 5月, 2019 2 次提交
    • K
      RDMA/core: Return void from ib_device_check_mandatory() · deee3c7e
      Kamal Heib 提交于
      The return value from ib_device_check_mandatory() is always 0 - change it
      to be void.
      Signed-off-by: NKamal Heib <kamalheib1@gmail.com>
      Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      deee3c7e
    • L
      RDMA/srp: Rename SRP sysfs name after IB device rename trigger · dc1435c0
      Leon Romanovsky 提交于
      SRP logic used device name and port index as symlink to relevant
      kobject. If the IB device is renamed then the prior name will be re-used
      by the next device plugged in and sysfs will panic as SRP will try to
      re-use the same name.
      
       mlx5_ib: Mellanox Connect-IB Infiniband driver v5.0-0
       sysfs: cannot create duplicate filename '/class/infiniband_srp/srp-mlx5_0-1'
       CPU: 3 PID: 1107 Comm: modprobe Not tainted 5.1.0-for-upstream-perf-2019-05-12_15-09-52-87 #1
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
       Call Trace:
        dump_stack+0x5a/0x73
        sysfs_warn_dup+0x58/0x70
        sysfs_do_create_link_sd.isra.2+0xa3/0xb0
        device_add+0x33f/0x660
        srp_add_one+0x301/0x4f0 [ib_srp]
        add_client_context+0x99/0xe0 [ib_core]
        enable_device_and_get+0xd1/0x1b0 [ib_core]
        ib_register_device+0x533/0x710 [ib_core]
        ? mutex_lock+0xe/0x30
        __mlx5_ib_add+0x23/0x70 [mlx5_ib]
        mlx5_add_device+0x4e/0xd0 [mlx5_core]
        mlx5_register_interface+0x85/0xc0 [mlx5_core]
        ? 0xffffffffa0791000
        do_one_initcall+0x4b/0x1cb
        ? kmem_cache_alloc_trace+0xc6/0x1d0
        ? do_init_module+0x22/0x21f
        do_init_module+0x5a/0x21f
        load_module+0x17f2/0x1ca0
        ? m_show+0x1c0/0x1c0
        __do_sys_finit_module+0x94/0xe0
        do_syscall_64+0x48/0x120
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7f157cce10d9
      
      The module load/unload sequence was used to trigger such kernel panic:
       sudo modprobe ib_srp
       sudo modprobe -r mlx5_ib
       sudo modprobe -r mlx5_core
       sudo modprobe mlx5_core
      
      Have SRP track the name of the core device so that it can't have a name
      collision.
      
      Fixes: d21943dd ("RDMA/core: Implement IB device rename function")
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      dc1435c0
  17. 08 5月, 2019 1 次提交
  18. 03 5月, 2019 2 次提交
  19. 02 5月, 2019 1 次提交
  20. 23 4月, 2019 3 次提交
    • P
      RDMA/core: Add a netlink command to change net namespace of rdma device · 2e5b8a01
      Parav Pandit 提交于
      Provide an option to change the net namespace of a rdma device through a
      netlink command. When multiple rdma devices exists in a system, and when
      containers are used, this will limit rdma device visibility to a specified
      net namespace.
      
      An example command to change net namespace of mlx5_1 device to the
      previously created net namespace 'foo' is:
      
      $ ip netns add foo
      $ rdma dev set mlx5_1 netns foo
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      2e5b8a01
    • P
      RDMA/core: Introduce a helper function to change net namespace of rdma device · decbc7a6
      Parav Pandit 提交于
      Introduce a helper function that changes rdma device's net namespace which
      performs mini disable/enable sequence to have device visible only in
      assigned net namespace.
      
      Device unregistration, device rename and device change net namespace
      may be invoked concurrently.
      
      (a) device unregistration needs to wait if a device change (rename or net
          namespace change) operation is in progress.
      (b) device net namespace change should not proceed if the unregistration
          has started.
      (c) while one cpu is changing device net namespace, other cpu should not
          be able to rename or change net namespace.
      
      To address above concurrency,
      (a) Use unreg_mutex to synchronize between ib_unregister_device() and net
          namespace change operation
      (b) In cases where unregister_device() has started unregistration before
          change_netns got chance to acquire unreg_mutex, validate the refcount
          - if it dropped to zero, abort the net namespace change operation.
      
      Finally use the helper function to change net namespace of ib device to
      move the device back to init_net when such net is deleted.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      decbc7a6
    • P
      RDMA/core: Avoid freeing netdevs in disable_device() · 3042492b
      Parav Pandit 提交于
      So we can use the disable_device() helper while changing the net namespace
      of the rdma device in a subsequent patch, move free_netdevs() out of it.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      3042492b
  21. 09 4月, 2019 3 次提交
  22. 29 3月, 2019 6 次提交