1. 30 8月, 2017 2 次提交
    • M
      IB/core: Add support to finalize objects in one transaction · f43dbebf
      Matan Barak 提交于
      The new ioctl based infrastructure either commits or rollbacks
      all objects of the method as one transaction. In order to do
      that, we introduce a notion of dealing with a collection of
      objects that are related to a specific method.
      
      This also requires adding a notion of a method and attribute.
      A method contains a hash of attributes, where each bucket
      contains several attributes. The attributes are hashed according
      to their namespace which resides in the four upper bits of the id.
      
      For example, an object could be a CQ, which has an action of CREATE_CQ.
      This action has multiple attributes. For example, the CQ's new handle
      and the comp_channel. Each layer in this hierarchy - objects, methods
      and attributes is split into namespaces. The basic example for that is
      one namespace representing the default entities and another one
      representing the driver specific entities.
      
      When declaring these methods and attributes, we actually declare
      their specifications. When a method is executed, we actually
      allocates some space to hold auxiliary information. This auxiliary
      information contains meta-data about the required objects, such
      as pointers to their type information, pointers to the uobjects
      themselves (if exist), etc.
      The specification, along with the auxiliary information we allocated
      and filled is given to the finalize_objects function.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Reviewed-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f43dbebf
    • M
      IB/core: Add a generic way to execute an operation on a uobject · a0aa309c
      Matan Barak 提交于
      The ioctl infrastructure treats all user-objects in the same manner.
      It gets objects ids from the user-space and by using the object type
      and type attributes mentioned in the object specification, it executes
      this required method. Passing an object id from the user-space as
      an attribute is carried out in three stages. The first is carried out
      before the actual handler and the last is carried out afterwards.
      
      The different supported operations are read, write, destroy and create.
      In the first stage, the former three actions just fetches the object
      from the repository (by using its id) and locks it. The last action
      allocates a new uobject. Afterwards, the second stage is carried out
      when the handler itself carries out the required modification of the
      object. The last stage is carried out after the handler finishes and
      commits the result. The former two operations just unlock the object.
      Destroy calls the "free object" operation, taking into account the
      object's type and releases the uobject as well. Creation just adds the
      new uobject to the repository, making the object visible to the
      application.
      
      In order to abstract these details from the ioctl infrastructure
      layer, we add uverbs_get_uobject_from_context and
      uverbs_finalize_object functions which corresponds to the first
      and last stages respectively.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Reviewed-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      a0aa309c
  2. 29 8月, 2017 3 次提交
  3. 25 8月, 2017 7 次提交
  4. 23 8月, 2017 5 次提交
  5. 19 8月, 2017 2 次提交
  6. 18 8月, 2017 3 次提交
  7. 17 8月, 2017 1 次提交
    • M
      IB/uverbs: Fix NULL pointer dereference during device removal · 870201f9
      Maor Gottlieb 提交于
      As part of ib_uverbs_remove_one which might be triggered upon
      reset flow, we trigger IB_EVENT_DEVICE_FATAL event to userspace
      application.
      If device was removed after uverbs fd was opened but before
      ib_uverbs_get_context was called, the event file will be accessed
      before it was allocated, result in NULL pointer dereference:
      
      [ 72.325873] BUG: unable to handle kernel NULL pointer dereference at (null)
      ...
      [ 72.325984] IP: _raw_spin_lock_irqsave+0x22/0x40
      [ 72.327123] Call Trace:
      [ 72.327168] ib_uverbs_async_handler.isra.8+0x2e/0x160 [ib_uverbs]
      [ 72.327216] ? synchronize_srcu_expedited+0x27/0x30
      [ 72.327269] ib_uverbs_remove_one+0x120/0x2c0 [ib_uverbs]
      [ 72.327330] ib_unregister_device+0xd0/0x180 [ib_core]
      [ 72.327373] mlx5_ib_remove+0x74/0x140 [mlx5_ib]
      [ 72.327422] mlx5_remove_device+0xfb/0x110 [mlx5_core]
      [ 72.327466] mlx5_unregister_interface+0x3c/0xa0 [mlx5_core]
      [ 72.327509] mlx5_ib_cleanup+0x10/0x962 [mlx5_ib]
      [ 72.327546] SyS_delete_module+0x155/0x230
      [ 72.328472] ? exit_to_usermode_loop+0x70/0xa6
      [ 72.329370] do_syscall_64+0x54/0xc0
      [ 72.330262] entry_SYSCALL64_slow_path+0x25/0x25
      
      Fix it by checking that user context was allocated before
      trigger the event.
      
      Fixes: 036b1063 ('IB/uverbs: Enable device removal when there are active user space applications')
      Signed-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Reviewed-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      870201f9
  8. 16 8月, 2017 1 次提交
    • S
      IB/core: Protect sysfs entry on ib_unregister_device · 06f8174a
      Shiraz Saleem 提交于
      ib_unregister_device is not protecting removal of sysfs entries.
      A call to ib_register_device in that window can result in
      duplicate sysfs entry warning. Move mutex_unlock to after
      ib_device_unregister_sysfs to protect against sysfs entry creation.
      
      This issue is exposed during driver load/unload stress test.
      
      WARNING: CPU: 5 PID: 4445 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5f/0x70
      sysfs: cannot create duplicate filename '/class/infiniband/i40iw0'
      Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Q87M-D2H
      BIOS F7 01/17/2014
      Workqueue: i40e i40e_service_task [i40e]
      Call Trace:
      dump_stack+0x67/0x98
      __warn+0xcc/0xf0
      warn_slowpath_fmt+0x4a/0x50
      ? kernfs_path_from_node+0x4b/0x60
      sysfs_warn_dup+0x5f/0x70
      sysfs_do_create_link_sd.isra.2+0xb7/0xc0
      sysfs_create_link+0x20/0x40
      device_add+0x28c/0x600
      ib_device_register_sysfs+0x58/0x170 [ib_core]
      ib_register_device+0x325/0x570 [ib_core]
      ? i40iw_register_rdma_device+0x1f4/0x400 [i40iw]
      ? kmem_cache_alloc_trace+0x143/0x330
      ? __raw_spin_lock_init+0x2d/0x50
      i40iw_register_rdma_device+0x2dc/0x400 [i40iw]
      i40iw_open+0x10a6/0x1950 [i40iw]
      ? i40iw_open+0xeab/0x1950 [i40iw]
      ? i40iw_make_cm_node+0x9c0/0x9c0 [i40iw]
      i40e_client_subtask+0xa4/0x110 [i40e]
      i40e_service_task+0xc2d/0x1320 [i40e]
      process_one_work+0x203/0x710
      ? process_one_work+0x16f/0x710
      worker_thread+0x126/0x4a0
      ? trace_hardirqs_on+0xd/0x10
      kthread+0x112/0x150
      ? process_one_work+0x710/0x710
      ? kthread_create_on_node+0x40/0x40
      ret_from_fork+0x2e/0x40
      ---[ end trace fd11b69e21ea7653 ]---
      Couldn't register device i40iw0 with driver model
      Signed-off-by: NShiraz Saleem <shiraz.saleem@intel.com>
      Signed-off-by: NSindhu Devale <sindhu.devale@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      06f8174a
  9. 10 8月, 2017 16 次提交