1. 27 11月, 2018 3 次提交
  2. 23 11月, 2018 3 次提交
  3. 21 9月, 2018 4 次提交
  4. 11 9月, 2018 2 次提交
  5. 06 9月, 2018 1 次提交
  6. 02 8月, 2018 2 次提交
    • J
      IB/uverbs: Do not pass struct ib_device to the write based methods · bbd51e88
      Jason Gunthorpe 提交于
      This is a step to get rid of the global check for disassociation. In this
      model, the ib_dev is not proven to be valid by the core code and cannot be
      provided to the method. Instead, every method decides if it is able to
      run after disassociation and obtains the ib_dev using one of three
      different approaches:
      
      - Call srcu_dereference on the udevice's ib_dev. As before, this means
        the method cannot be called after disassociation begins.
        (eg alloc ucontext)
      - Retrieve the ib_dev from the ucontext, via ib_uverbs_get_ucontext()
      - Retrieve the ib_dev from the uobject->object after checking
        under SRCU if disassociation has started (eg uobj_get)
      
      Largely, the code is all ready for this, the main work is to provide a
      ib_dev after calling uobj_alloc(). The few other places simply use
      ib_uverbs_get_ucontext() to get the ib_dev.
      
      This flexibility will let the next patches allow destroy to operate
      after disassociation.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      bbd51e88
    • J
      IB/uverbs: Make the write path destroy methods use the same flow as ioctl · 32ed5c00
      Jason Gunthorpe 提交于
      The ridiculous dance with uobj_remove_commit() is not needed, the write
      path can follow the same flow as ioctl - lock and destroy the HW object
      then use the data left over in the uobject to form the response to
      userspace.
      
      Two helpers are introduced to make this flow straightforward for the
      caller.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      32ed5c00
  7. 31 7月, 2018 2 次提交
  8. 26 7月, 2018 4 次提交
    • 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/uverbs: Always propagate errors from rdma_alloc_commit_uobject() · 2c96eb7d
      Jason Gunthorpe 提交于
      The ioctl framework already does this correctly, but the write path did
      not. This is trivially fixed by simply using a standard pattern to return
      uobj_alloc_commit() as the last statement in every function.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      2c96eb7d
    • J
      IB/uverbs: Rework the locking for cleaning up the ucontext · e951747a
      Jason Gunthorpe 提交于
      The locking here has always been a bit crazy and spread out, upon some
      careful analysis we can simplify things.
      
      Create a single function uverbs_destroy_ufile_hw() that internally handles
      all locking. This pulls together pieces of this process that were
      sprinkled all over the places into one place, and covers them with one
      lock.
      
      This eliminates several duplicate/confusing locks and makes the control
      flow in ib_uverbs_close() and ib_uverbs_free_hw_resources() extremely
      simple.
      
      Unfortunately we have to keep an extra mutex, ucontext_lock.  This lock is
      logically part of the rwsem and provides the 'down write, fail if write
      locked, wait if read locked' semantic we require.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      e951747a
    • J
      IB/uverbs: Handle IDR and FD types without truncation · 1250c304
      Jason Gunthorpe 提交于
      Our ABI for write() uses a s32 for FDs and a u32 for IDRs, but internally
      we ended up implicitly casting these ABI values into an 'int'. For ioctl()
      we use a s64 for FDs and a u64 for IDRs, again casting to an int.
      
      The various casts to int are all missing range checks which can cause
      userspace values that should be considered invalid to be accepted.
      
      Fix this by making the generic lookup routine accept a s64, which does not
      truncate the write API's u32/s32 or the ioctl API's s64. Then push the
      detailed range checking down to the actual type implementations to be
      shared by both interfaces.
      
      Finally, change the copy of the uobj->id to sign extend into a s64, so eg,
      if we ever wish to return a negative value for a FD it is carried
      properly.
      
      This ensures that userspace values are never weirdly interpreted due to
      the various trunctations and everything that is really out of range gets
      an EINVAL.
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      1250c304
  9. 25 7月, 2018 2 次提交
  10. 11 7月, 2018 2 次提交
  11. 10 7月, 2018 5 次提交
  12. 04 7月, 2018 1 次提交
  13. 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
  14. 27 6月, 2018 2 次提交
  15. 26 6月, 2018 4 次提交
    • L
      RDMA/uverbs: Fix slab-out-of-bounds in ib_uverbs_ex_create_flow · 4fae7f17
      Leon Romanovsky 提交于
      The check of cmd.flow_attr.size should check into account the size of the
      reserved field (2 bytes), otherwise user can provide a size which will
      cause a slab-out-of-bounds warning below.
      
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in ib_uverbs_ex_create_flow+0x1740/0x1d00
      Read of size 2 at addr ffff880068dff1a6 by task syz-executor775/269
      
      CPU: 0 PID: 269 Comm: syz-executor775 Not tainted 4.18.0-rc1+ #245
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
      Call Trace:
       dump_stack+0xef/0x17e
       print_address_description+0x83/0x3b0
       kasan_report+0x18d/0x4d0
       ib_uverbs_ex_create_flow+0x1740/0x1d00
       ib_uverbs_write+0x923/0x1010
       __vfs_write+0x10d/0x720
       vfs_write+0x1b0/0x550
       ksys_write+0xc6/0x1a0
       do_syscall_64+0xa7/0x590
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x433899
      Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89
      f7 48 89 d6 48 89 ca 4d 89 c2 4d
      89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 91 fd ff c3 66
      2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffc2724db58 EFLAGS: 00000217 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000020006880 RCX: 0000000000433899
      RDX: 00000000000000e0 RSI: 0000000020002480 RDI: 0000000000000003
      RBP: 00000000006d7018 R08: 00000000004002f8 R09: 00000000004002f8
      R10: 00000000004002f8 R11: 0000000000000217 R12: 0000000000000000
      
      R13: 000000000040cd20 R14: 000000000040cdb0 R15: 0000000000000006
      
      Allocated by task 269:
       kasan_kmalloc+0xa0/0xd0
       __kmalloc+0x1a9/0x510
       ib_uverbs_ex_create_flow+0x26c/0x1d00
       ib_uverbs_write+0x923/0x1010
       __vfs_write+0x10d/0x720
       vfs_write+0x1b0/0x550
       ksys_write+0xc6/0x1a0
       do_syscall_64+0xa7/0x590
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 0:
       __kasan_slab_free+0x12e/0x180
       kfree+0x159/0x630
       detach_buf+0x559/0x7a0
       virtqueue_get_buf_ctx+0x3cc/0xab0
       virtblk_done+0x1eb/0x3d0
       vring_interrupt+0x16d/0x2b0
       __handle_irq_event_percpu+0x10a/0x980
       handle_irq_event_percpu+0x77/0x190
       handle_irq_event+0xc6/0x1a0
       handle_edge_irq+0x211/0xd80
       handle_irq+0x3d/0x60
       do_IRQ+0x9b/0x220
      
      The buggy address belongs to the object at ffff880068dff180
       which belongs to the cache kmalloc-64 of size 64
      The buggy address is located 38 bytes inside of
       64-byte region [ffff880068dff180, ffff880068dff1c0)
      The buggy address belongs to the page:
      page:ffffea0001a37fc0 count:1 mapcount:0 mapping:ffff88006c401780
      index:0x0
      flags: 0x4000000000000100(slab)
      raw: 4000000000000100 ffffea0001a31100 0000001100000011 ffff88006c401780
      raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff880068dff080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
       ffff880068dff100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
      >ffff880068dff180: 00 00 00 00 07 fc fc fc fc fc fc fc fb fb fb fb
                                     ^
       ffff880068dff200: fb fb fb fb fc fc fc fc 00 00 00 00 00 00 fc fc
       ffff880068dff280: fc fc fc fc 00 00 00 00 00 00 00 00 fc fc fc fc
      ==================================================================
      
      Cc: <stable@vger.kernel.org> # 3.12
      Fixes: f8848274 ("IB/core: clarify overflow/underflow checks on ib_create/destroy_flow")
      Cc: syzkaller <syzkaller@googlegroups.com>
      Reported-by: NNoa Osherovich <noaos@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      4fae7f17
    • L
      RDMA/uverbs: Protect from attempts to create flows on unsupported QP · 940efcc8
      Leon Romanovsky 提交于
      Flows can be created on UD and RAW_PACKET QP types. Attempts to provide
      other QP types as an input causes to various unpredictable failures.
      
      The reason is that in order to support all various types (e.g. XRC), we
      are supposed to use real_qp handle and not qp handle and expect to
      driver/FW to fail such (XRC) flows. The simpler and safer variant is to
      ban all QP types except UD and RAW_PACKET, instead of relying on
      driver/FW.
      
      Cc: <stable@vger.kernel.org> # 3.11
      Fixes: 436f2ad0 ("IB/core: Export ib_create/destroy_flow through uverbs")
      Cc: syzkaller <syzkaller@googlegroups.com>
      Reported-by: NNoa Osherovich <noaos@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      940efcc8
    • L
      RDMA/verbs: Drop kernel variant of destroy_flow · 1ccddc42
      Leon Romanovsky 提交于
      Following the removal of ib_create_flow(), adjust the code to get rid of
      ib_destroy_flow() too.
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      1ccddc42
    • J
      RDMA/uverbs: Check existence of create_flow callback · e99028ad
      Jason Gunthorpe 提交于
      In the accepted series "Refactor ib_uverbs_write path", we presented the
      roadmap to get rid of uverbs_cmd_mask and uverbs_ex_cmd_mask fields in
      favor of simple check of function pointer. So let's put NULL check of
      create_flow function callback despite the fact that uverbs_ex_cmd_mask
      still exists.
      
      Link: https://www.spinics.net/lists/linux-rdma/msg60753.htmlSuggested-by: NMichael J Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      e99028ad
  16. 19 6月, 2018 2 次提交