Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 1月, 2019 1 次提交
  3. 11 1月, 2019 1 次提交
  5. 21 12月, 2018 1 次提交
  7. 07 12月, 2018 1 次提交
  9. 05 12月, 2018 3 次提交
  11. 30 11月, 2018 1 次提交
  13. 27 11月, 2018 2 次提交
  15. 23 11月, 2018 2 次提交
  17. 16 10月, 2018 1 次提交
  19. 28 9月, 2018 2 次提交
  21. 26 9月, 2018 2 次提交
  23. 05 9月, 2018 1 次提交
  25. 13 8月, 2018 1 次提交
  27. 02 8月, 2018 1 次提交
    • J
      IB/uverbs: Do not pass struct ib_device to the ioctl methods · e83f0ecd
      由 Jason Gunthorpe 提交于 
      This does the same as the patch before, except for ioctl. The rules are
the same, but for the ioctl methods the core code handles setting up the
uobject.

- Retrieve the ib_dev from the uobject->context->device. This is
  safe under ioctl as the core has already done rdma_alloc_begin_uobject
  and so CREATE calls are entirely protected by the rwsem.
- Retrieve the ib_dev from uobject->object
- Call ib_uverbs_get_ucontext()
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      e83f0ecd
  29. 31 7月, 2018 1 次提交
    • J
      IB/uverbs: Add UVERBS_ATTR_FLAGS_IN to the specs language · bccd0622
      由 Jason Gunthorpe 提交于 
      This clearly indicates that the input is a bitwise combination of values
in an enum, and identifies which enum contains the definition of the bits.

Special accessors are provided that handle the mandatory validation of the
allowed bits and enforce the correct type for bitwise flags.

If we had introduced this at the start then the kabi would have uniformly
used u64 data to pass flags, however today there is a mixture of u64 and
u32 flags. All places are converted to accept both sizes and the accessor
fixes it. This allows all existing flags to grow to u64 in future without
any hassle.

Finally all flags are, by definition, optional. If flags are not passed
the accessor does not fail, but provides a value of zero.
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      bccd0622
  31. 26 7月, 2018 2 次提交
    • J
      IB/uverbs: Fix locking around struct ib_uverbs_file ucontext · 22fa27fb
      由 Jason Gunthorpe 提交于 
      We have a parallel unlocked reader and writer with ib_uverbs_get_context()
vs everything else, and nothing guarantees this works properly.

Audit and fix all of the places that access ucontext to use one of the
following locking schemes:
- Call ib_uverbs_get_ucontext() under SRCU and check for failure
- Access the ucontext through an struct ib_uobject context member
  while holding a READ or WRITE lock on the uobject.
  This value cannot be NULL and has no race.
- Hold the ucontext_lock and check for ufile->ucontext !NULL

This also re-implements ib_uverbs_get_ucontext() in a way that is safe
against concurrent ib_uverbs_get_context() and disassociation.

As a side effect, every access to ucontext in the commands is via
ib_uverbs_get_context() with an error check, or via the uobject, so there
is no longer any need for the core code to check ucontext on every command
call. These checks are also removed.
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      22fa27fb
    • J
      IB/mlx5: Use the ucontext from the uobj, not the file · c36ee46d
      由 Jason Gunthorpe 提交于 
      This approach matches the standard flow of the typical write method that
relies on the HW object to store the device and the uobject to access the
ucontext.  Avoids the use of the devx_ufile2uctx in several places will
make revising the semantics of ib_uverbs_get_ucontext() in the next patch
simpler.
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      c36ee46d
  33. 25 7月, 2018 1 次提交
  35. 24 7月, 2018 1 次提交
  37. 11 7月, 2018 1 次提交
  39. 05 7月, 2018 6 次提交
  41. 30 6月, 2018 1 次提交
    • Y
      IB: Improve uverbs_cleanup_ucontext algorithm · 1c77483e
      由 Yishai Hadas 提交于 
      Improve uverbs_cleanup_ucontext algorithm to work properly when the
topology graph of the objects cannot be determined at compile time.  This
is the case with objects created via the devx interface in mlx5.

Typically uverbs objects must be created in a strict topologically sorted
order, so that LIFO ordering will generally cause them to be freed
properly. There are only a few cases (eg memory windows) where objects can
point to things out of the strict LIFO order.

Instead of using an explicit ordering scheme where the HW destroy is not
allowed to fail, go over the list multiple times and allow the destroy
function to fail. If progress halts then a final, desperate, cleanup is
done before leaking the memory. This indicates a driver bug.
Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      1c77483e
  43. 20 6月, 2018 7 次提交