1. 22 10月, 2015 1 次提交
    • A
      IB/core: avoid 32-bit warning · 5d1e6235
      Arnd Bergmann 提交于
      The INIT_UDATA() macro requires a pointer or unsigned long argument for
      both input and output buffer, and all callers had a cast from when
      the code was merged until a recent restructuring, so now we get
      
      core/uverbs_cmd.c: In function 'ib_uverbs_create_cq':
      core/uverbs_cmd.c:1481:66: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      
      This makes the code behave as before by adding back the cast to
      unsigned long.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 565197dd ("IB/core: Extend ib_uverbs_create_cq")
      Reviewed-by: NYann Droneaud <ydroneaud@opteya.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      5d1e6235
  2. 04 9月, 2015 1 次提交
  3. 31 8月, 2015 4 次提交
  4. 13 6月, 2015 4 次提交
  5. 19 2月, 2015 2 次提交
  6. 18 2月, 2015 1 次提交
  7. 06 2月, 2015 1 次提交
  8. 16 12月, 2014 4 次提交
    • H
      IB/core: Implement support for MMU notifiers regarding on demand paging regions · 882214e2
      Haggai Eran 提交于
      * Add an interval tree implementation for ODP umems. Create an
        interval tree for each ucontext (including a count of the number of
        ODP MRs in this context, semaphore, etc.), and register ODP umems in
        the interval tree.
      * Add MMU notifiers handling functions, using the interval tree to
        notify only the relevant umems and underlying MRs.
      * Register to receive MMU notifier events from the MM subsystem upon
        ODP MR registration (and unregister accordingly).
      * Add a completion object to synchronize the destruction of ODP umems.
      * Add mechanism to abort page faults when there's a concurrent invalidation.
      
      The way we synchronize between concurrent invalidations and page
      faults is by keeping a counter of currently running invalidations, and
      a sequence number that is incremented whenever an invalidation is
      caught. The page fault code checks the counter and also verifies that
      the sequence number hasn't progressed before it updates the umem's
      page tables. This is similar to what the kvm module does.
      
      In order to prevent the case where we register a umem in the middle of
      an ongoing notifier, we also keep a per ucontext counter of the total
      number of active mmu notifiers. We only enable new umems when all the
      running notifiers complete.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NShachar Raindel <raindel@mellanox.com>
      Signed-off-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NYuval Dagan <yuvalda@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      882214e2
    • S
      IB/core: Add support for on demand paging regions · 8ada2c1c
      Shachar Raindel 提交于
      * Extend the umem struct to keep the ODP related data.
      * Allocate and initialize the ODP related information in the umem
        (page_list, dma_list) and freeing as needed in the end of the run.
      * Store a reference to the process PID struct in the ucontext.  Used to
        safely obtain the task_struct and the mm during fault handling,
        without preventing the task destruction if needed.
      * Add 2 helper functions: ib_umem_odp_map_dma_pages and
        ib_umem_odp_unmap_dma_pages. These functions get the DMA addresses
        of specific pages of the umem (and, currently, pin them).
      * Support for page faults only - IB core will keep the reference on
        the pages used and call put_page when freeing an ODP umem
        area. Invalidations support will be added in a later patch.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NShachar Raindel <raindel@mellanox.com>
      Signed-off-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      8ada2c1c
    • S
      IB/core: Add flags for on demand paging support · 860f10a7
      Sagi Grimberg 提交于
      * Add a configuration option for enable on-demand paging support in
        the infiniband subsystem (CONFIG_INFINIBAND_ON_DEMAND_PAGING). In a
        later patch, this configuration option will select the MMU_NOTIFIER
        configuration option to enable mmu notifiers.
      * Add a flag for on demand paging (ODP) support in the IB device capabilities.
      * Add a flag to request ODP MR in the access flags to reg_mr.
      * Fail registrations done with the ODP flag when the low-level driver
        doesn't support this.
      * Change the conditions in which an MR will be writable to explicitly
        specify the access flags.  This is to avoid making an MR writable just
        because it is an ODP MR.
      * Add a ODP capabilities to the extended query device verb.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NShachar Raindel <raindel@mellanox.com>
      Signed-off-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      860f10a7
    • E
      IB/core: Add support for extended query device caps · 5a77abf9
      Eli Cohen 提交于
      Add extensible query device capabilities verb to allow adding new features.
      ib_uverbs_ex_query_device is added and copy_query_dev_fields is used to
      copy capability fields to be used by both ib_uverbs_query_device and
      ib_uverbs_ex_query_device.
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Signed-off-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      5a77abf9
  9. 14 10月, 2014 1 次提交
  10. 02 8月, 2014 1 次提交
  11. 20 1月, 2014 1 次提交
  12. 21 12月, 2013 4 次提交
  13. 18 11月, 2013 5 次提交
    • M
      IB/core: Re-enable create_flow/destroy_flow uverbs · 69ad5da4
      Matan Barak 提交于
      This commit reverts commit 7afbddfa ("IB/core: Temporarily disable
      create_flow/destroy_flow uverbs").  Since the uverbs extensions
      functionality was experimental for v3.12, this patch re-enables the
      support for them and flow-steering for v3.13.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      69ad5da4
    • Y
      IB/core: extended command: an improved infrastructure for uverbs commands · f21519b2
      Yann Droneaud 提交于
      Commit 400dbc96 ("IB/core: Infrastructure for extensible uverbs
      commands") added an infrastructure for extensible uverbs commands
      while later commit 436f2ad0 ("IB/core: Export ib_create/destroy_flow
      through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
      using this new infrastructure.
      
      According to the commit 400dbc96, the purpose of this
      infrastructure is to support passing around provider (eg. hardware)
      specific buffers when userspace issue commands to the kernel, so that
      it would be possible to extend uverbs (eg. core) buffers independently
      from the provider buffers.
      
      But the new kernel command function prototypes were not modified to
      take advantage of this extension. This issue was exposed by Roland
      Dreier in a previous review[1].
      
      So the following patch is an attempt to a revised extensible command
      infrastructure.
      
      This improved extensible command infrastructure distinguish between
      core (eg. legacy)'s command/response buffers from provider
      (eg. hardware)'s command/response buffers: each extended command
      implementing function is given a struct ib_udata to hold core
      (eg. uverbs) input and output buffers, and another struct ib_udata to
      hold the hw (eg. provider) input and output buffers.
      
      Having those buffers identified separately make it easier to increase
      one buffer to support extension without having to add some code to
      guess the exact size of each command/response parts: This should make
      the extended functions more reliable.
      
      Additionally, instead of relying on command identifier being greater
      than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
      unused bits in command field: on the 32 bits provided by command
      field, only 6 bits are really needed to encode the identifier of
      commands currently supported by the kernel. (Even using only 6 bits
      leaves room for about 23 new commands).
      
      So this patch makes use of some high order bits in command field to
      store flags, leaving enough room for more command identifiers than one
      will ever need (eg. 256).
      
      The new flags are used to specify if the command should be processed
      as an extended one or a legacy one. While designing the new command
      format, care was taken to make usage of flags itself extensible.
      
      Using high order bits of the commands field ensure that newer
      libibverbs on older kernel will properly fail when trying to call
      extended commands. On the other hand, older libibverbs on newer kernel
      will never be able to issue calls to extended commands.
      
      The extended command header includes the optional response pointer so
      that output buffer length and output buffer pointer are located
      together in the command, allowing proper parameters checking. This
      should make implementing functions easier and safer.
      
      Additionally the extended header ensure 64bits alignment, while making
      all sizes multiple of 8 bytes, extending the maximum buffer size:
      
                                   legacy      extended
      
         Maximum command buffer:  256KBytes   1024KBytes (512KBytes + 512KBytes)
        Maximum response buffer:  256KBytes   1024KBytes (512KBytes + 512KBytes)
      
      For the purpose of doing proper buffer size accounting, the headers
      size are no more taken in account in "in_words".
      
      One of the odds of the current extensible infrastructure, reading
      twice the "legacy" command header, is fixed by removing the "legacy"
      command header from the extended command header: they are processed as
      two different parts of the command: memory is read once and
      information are not duplicated: it's making clear that's an extended
      command scheme and not a different command scheme.
      
      The proposed scheme will format input (command) and output (response)
      buffers this way:
      
      - command:
      
        legacy header +
        extended header +
        command data (core + hw):
      
          +----------------------------------------+
          | flags     |   00      00    |  command |
          |        in_words    |   out_words       |
          +----------------------------------------+
          |                 response               |
          |                 response               |
          | provider_in_words | provider_out_words |
          |                 padding                |
          +----------------------------------------+
          |                                        |
          .              <uverbs input>            .
          .              (in_words * 8)            .
          |                                        |
          +----------------------------------------+
          |                                        |
          .             <provider input>           .
          .          (provider_in_words * 8)       .
          |                                        |
          +----------------------------------------+
      
      - response, if present:
      
          +----------------------------------------+
          |                                        |
          .          <uverbs output space>         .
          .             (out_words * 8)            .
          |                                        |
          +----------------------------------------+
          |                                        |
          .         <provider output space>        .
          .         (provider_out_words * 8)       .
          |                                        |
          +----------------------------------------+
      
      The overall design is to ensure that the extensible infrastructure is
      itself extensible while begin more reliable with more input and bound
      checking.
      
      Note:
      
      The unused field in the extended header would be perfect candidate to
      hold the command "comp_mask" (eg. bit field used to handle
      compatibility).  This was suggested by Roland Dreier in a previous
      review[2].  But "comp_mask" field is likely to be present in the uverb
      input and/or provider input, likewise for the response, as noted by
      Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
      header.
      
      [1]:
      http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
      
      [2]:
      http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
      
      [3]:
      http://marc.info/?i=525C1149.6000701@mellanox.comSigned-off-by: NYann Droneaud <ydroneaud@opteya.com>
      Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
      
      [ Convert "ret ? ret : 0" to the equivalent "ret".  - Roland ]
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f21519b2
    • Y
      IB/core: Make uverbs flow structure use names like verbs ones · b68c9560
      Yann Droneaud 提交于
      This patch adds "flow" prefix to most of data structure added as part
      of commit 436f2ad0 ("IB/core: Export ib_create/destroy_flow through
      uverbs") to keep those names in sync with the data structures added in
      commit 319a441d ("IB/core: Add receive flow steering support").
      
      It's just a matter of translating 'ib_flow' to 'ib_uverbs_flow'.
      Signed-off-by: NYann Droneaud <ydroneaud@opteya.com>
      Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.comSigned-off-by: NRoland Dreier <roland@purestorage.com>
      b68c9560
    • Y
      IB/core: Rename 'flow' structs to match other uverbs structs · d82693da
      Yann Droneaud 提交于
      Commit 436f2ad0 ("IB/core: Export ib_create/destroy_flow through
      uverbs") added public data structures to support receive flow
      steering.  The new structs are not following the 'uverbs' pattern:
      they're lacking the common prefix 'ib_uverbs'.
      
      This patch replaces ib_kern prefix by ib_uverbs.
      Signed-off-by: NYann Droneaud <ydroneaud@opteya.com>
      Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.comSigned-off-by: NRoland Dreier <roland@purestorage.com>
      d82693da
    • M
      IB/core: clarify overflow/underflow checks on ib_create/destroy_flow · f8848274
      Matan Barak 提交于
      This patch fixes the following issues:
      
      1. Unneeded checks were removed
      
      2. Removed the fixed size out of flow_attr.size, thus simplifying the checks.
      
      3. Remove a 32bit hole on 64bit systems with strict alignment in
         struct ib_kern_flow_att by adding a reserved field.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f8848274
  14. 16 11月, 2013 1 次提交
  15. 09 11月, 2013 1 次提交
  16. 22 10月, 2013 1 次提交
  17. 03 9月, 2013 1 次提交
  18. 29 8月, 2013 1 次提交
  19. 14 8月, 2013 1 次提交
  20. 09 7月, 2013 1 次提交
    • R
      IB/uverbs: Use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd() · da183c7a
      Roland Dreier 提交于
      The macro get_unused_fd() is used to allocate a file descriptor with
      default flags.  Those default flags (0) can be "unsafe": O_CLOEXEC must
      be used by default to not leak file descriptor across exec().
      
      Replace calls to get_unused_fd() in uverbs with calls to
      get_unused_fd_flags(O_CLOEXEC).  Inheriting uverbs fds across exec()
      cannot be used to do anything useful.
      
      Based on a patch/suggestion from Yann Droneaud <ydroneaud@opteya.com>.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      da183c7a
  21. 28 2月, 2013 1 次提交
  22. 23 2月, 2013 1 次提交
  23. 22 2月, 2013 1 次提交