1. 05 8月, 2017 1 次提交
  2. 20 4月, 2017 2 次提交
  3. 06 4月, 2017 5 次提交
  4. 21 3月, 2017 1 次提交
  5. 25 1月, 2017 1 次提交
  6. 11 1月, 2017 1 次提交
    • P
      IB/core: added support to use rdma cgroup controller · 43579b5f
      Parav Pandit 提交于
      Added support APIs for IB core to register/unregister every IB/RDMA
      device with rdma cgroup for tracking rdma resources.
      IB core registers with rdma cgroup controller.
      Added support APIs for uverbs layer to make use of rdma controller.
      Added uverbs layer to perform resource charge/uncharge functionality.
      Added support during query_device uverb operation to ensure it
      returns resource limits by honoring rdma cgroup configured limits.
      Signed-off-by: NParav Pandit <pandit.parav@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      43579b5f
  7. 25 12月, 2016 1 次提交
  8. 14 12月, 2016 1 次提交
  9. 04 12月, 2016 1 次提交
    • L
      infiniband: remove WARN that is not kernel bug · f73a1dbc
      Leon Romanovsky 提交于
      On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote:
      > On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
      > > >
      > > > In ib_ucm_write function there is a wrong prefix:
      > > >
      > > > + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
      > >
      > > I did it intentionally to have the same errors for all flows.
      >
      > Lets actually use a good message too please?
      >
      >  pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
      >
      > Jason
      
      >From 70f95b2d35aea42e5b97e7d27ab2f4e8effcbe67 Mon Sep 17 00:00:00 2001
      From: Leon Romanovsky <leonro@mellanox.com>
      Date: Mon, 21 Nov 2016 13:30:59 +0200
      Subject: [PATCH rdma-next V2] IB/{core, qib}: Remove WARN that is not kernel bug
      
      WARNINGs mean kernel bugs, in this case, they are placed
      to mark programming errors and/or malicious attempts.
      
      BUG/WARNs that are not kernel bugs hinder automated testing efforts.
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f73a1dbc
  10. 17 11月, 2016 1 次提交
  11. 04 8月, 2016 1 次提交
  12. 23 6月, 2016 2 次提交
  13. 29 4月, 2016 1 次提交
    • J
      IB/security: Restrict use of the write() interface · e6bd18f5
      Jason Gunthorpe 提交于
      The drivers/infiniband stack uses write() as a replacement for
      bi-directional ioctl().  This is not safe. There are ways to
      trigger write calls that result in the return structure that
      is normally written to user space being shunted off to user
      specified kernel memory instead.
      
      For the immediate repair, detect and deny suspicious accesses to
      the write API.
      
      For long term, update the user space libraries and the kernel API
      to something that doesn't present the same security vulnerabilities
      (likely a structured ioctl() interface).
      
      The impacted uAPI interfaces are generally only available if
      hardware from drivers/infiniband is installed in the system.
      Reported-by: NJann Horn <jann@thejh.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      [ Expanded check to all known write() entry points ]
      Cc: stable@vger.kernel.org
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      e6bd18f5
  14. 03 3月, 2016 4 次提交
  15. 24 12月, 2015 1 次提交
  16. 22 10月, 2015 1 次提交
  17. 31 8月, 2015 5 次提交
  18. 13 6月, 2015 1 次提交
  19. 16 4月, 2015 1 次提交
    • S
      ib_uverbs: Fix pages leak when using XRC SRQs · a233c4b5
      Sébastien Dugué 提交于
      Hello,
      
        When an application using XRCs abruptly terminates, the mmaped pages
      of the CQ buffers are leaked.
      
        This comes from the fact that when resources are released in
      ib_uverbs_cleanup_ucontext(), we fail to release the CQs because their
      refcount is not 0.
      
        When creating an XRC SRQ, we increment the associated CQ refcount.
      This refcount is only decremented when the SRQ is released.
      
        Therefore we need to release the SRQs prior to the CQs to make sure
      that all references to the CQs are gone before trying to release these.
      Signed-off-by: NSebastien Dugue <sebastien.dugue@bull.net>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      a233c4b5
  20. 19 2月, 2015 1 次提交
  21. 04 2月, 2015 1 次提交
  22. 16 12月, 2014 2 次提交
  23. 14 10月, 2014 1 次提交
    • J
      IB/core: Fix XRC race condition in ib_uverbs_open_qp · a040f95d
      Jack Morgenstein 提交于
      In ib_uverbs_open_qp, the sharable xrc target qp is created as a
      "pseudo" qp and added to a list of qp's sharing the same physical
      QP.  This is done before the "pseudo" qp is assigned a uobject.
      
      There is a race condition here if an async event arrives at the
      physical qp.  If the event is handled after the pseudo qp is added to
      the list, but before it is assigned a uobject, the kernel crashes in
      ib_uverbs_qp_event_handler, due to trying to dereference a NULL
      uobject pointer.
      
      Note that simply checking for non-NULL is not enough, due to error
      flows in ib_uverbs_open_qp.  If the failure is after assigning the
      uobject, but before the qp has fully been created, we still have a
      problem.
      
      Thus, in ib_uverbs_qp_event_handler, we test that the uobject is
      present, and also that it is live.
      Reported-by: NMatthew Finlay <matt@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      a040f95d
  24. 09 10月, 2014 1 次提交
  25. 02 8月, 2014 1 次提交
  26. 21 12月, 2013 1 次提交