<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/linux/mlx5/cq.h, branch linux-4.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.15.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.15.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2017-11-15T22:54:53Z</updated>
<entry>
<title>Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma</title>
<updated>2017-11-15T22:54:53Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-11-15T22:54:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ad0835a93008e5901415a0a27847d6a27649aa3a'/>
<id>urn:sha1:ad0835a93008e5901415a0a27847d6a27649aa3a</id>
<content type='text'>
Pull rdma updates from Doug Ledford:
 "This is a fairly plain pull request. Lots of driver updates across the
  stack, a huge number of static analysis cleanups including a close to
  50 patch series from Bart Van Assche, and a number of new features
  inside the stack such as general CQ moderation support.

  Nothing really stands out, but there might be a few conflicts as you
  take things in. In particular, the cleanups touched some of the same
  lines as the new timer_setup changes.

  Everything in this pull request has been through 0day and at least two
  days of linux-next (since Stephen doesn't necessarily flag new
  errors/warnings until day2). A few more items (about 30 patches) from
  Intel and Mellanox showed up on the list on Tuesday. I've excluded
  those from this pull request, and I'm sure some of them qualify as
  fixes suitable to send any time, but I still have to review them
  fully. If they contain mostly fixes and little or no new development,
  then I will probably send them through by the end of the week just to
  get them out of the way.

  There was a break in my acceptance of patches which coincides with the
  computer problems I had, and then when I got things mostly back under
  control I had a backlog of patches to process, which I did mostly last
  Friday and Monday. So there is a larger number of patches processed in
  that timeframe than I was striving for.

  Summary:
   - Add iWARP support to qedr driver
   - Lots of misc fixes across subsystem
   - Multiple update series to hns roce driver
   - Multiple update series to hfi1 driver
   - Updates to vnic driver
   - Add kref to wait struct in cxgb4 driver
   - Updates to i40iw driver
   - Mellanox shared pull request
   - timer_setup changes
   - massive cleanup series from Bart Van Assche
   - Two series of SRP/SRPT changes from Bart Van Assche
   - Core updates from Mellanox
   - i40iw updates
   - IPoIB updates
   - mlx5 updates
   - mlx4 updates
   - hns updates
   - bnxt_re fixes
   - PCI write padding support
   - Sparse/Smatch/warning cleanups/fixes
   - CQ moderation support
   - SRQ support in vmw_pvrdma"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (296 commits)
  RDMA/core: Rename kernel modify_cq to better describe its usage
  IB/mlx5: Add CQ moderation capability to query_device
  IB/mlx4: Add CQ moderation capability to query_device
  IB/uverbs: Add CQ moderation capability to query_device
  IB/mlx5: Exposing modify CQ callback to uverbs layer
  IB/mlx4: Exposing modify CQ callback to uverbs layer
  IB/uverbs: Allow CQ moderation with modify CQ
  iw_cxgb4: atomically flush the qp
  iw_cxgb4: only call the cq comp_handler when the cq is armed
  iw_cxgb4: Fix possible circular dependency locking warning
  RDMA/bnxt_re: report vlan_id and sl in qp1 recv completion
  IB/core: Only maintain real QPs in the security lists
  IB/ocrdma_hw: remove unnecessary code in ocrdma_mbx_dealloc_lkey
  RDMA/core: Make function rdma_copy_addr return void
  RDMA/vmw_pvrdma: Add shared receive queue support
  RDMA/core: avoid uninitialized variable warning in create_udata
  RDMA/bnxt_re: synchronize poll_cq and req_notify_cq verbs
  RDMA/bnxt_re: Flush CQ notification Work Queue before destroying QP
  RDMA/bnxt_re: Set QP state in case of response completion errors
  RDMA/bnxt_re: Add memory barriers when processing CQ/EQ entries
  ...
</content>
</entry>
<entry>
<title>IB/mlx5: Exposing modify CQ callback to uverbs layer</title>
<updated>2017-11-13T21:59:22Z</updated>
<author>
<name>Yonatan Cohen</name>
<email>yonatanc@mellanox.com</email>
</author>
<published>2017-11-13T08:51:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b0e9df6da25890448ebd134b7f647f16bced9abc'/>
<id>urn:sha1:b0e9df6da25890448ebd134b7f647f16bced9abc</id>
<content type='text'>
Exposed mlx5_ib_modify_cq to be called from ib device
verb list.

Signed-off-by: Yonatan Cohen &lt;yonatanc@mellanox.com&gt;
Reviewed-by: Majd Dibbiny &lt;majd@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>IB/mlx5: Support padded 128B CQE feature</title>
<updated>2017-10-25T18:17:06Z</updated>
<author>
<name>Guy Levi</name>
<email>guyle@mellanox.com</email>
</author>
<published>2017-10-19T05:25:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7a0c8f4244e9ec7a630563d294b211342b46223d'/>
<id>urn:sha1:7a0c8f4244e9ec7a630563d294b211342b46223d</id>
<content type='text'>
In some benchmarks and some CPU architectures, writing the CQE on a full
cache line size improves performance by saving memory access operations
(read-modify-write) relative to partial cache line change. This patch
lets the user to configure the device to pad the CQE up to 128B in case
its content is less than 128B. Currently the driver supports only padding
for a CQE size of 128B.

Signed-off-by: Guy Levi &lt;guyle@mellanox.com&gt;
Reviewed-by: Mark Bloch &lt;markb@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>drivers, net, mlx5: convert mlx5_cq.refcount from atomic_t to refcount_t</title>
<updated>2017-10-22T01:22:38Z</updated>
<author>
<name>Elena Reshetova</name>
<email>elena.reshetova@intel.com</email>
</author>
<published>2017-10-20T07:23:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a4b51a9f83c6d359ff8fc0c66009283b6fdeeaf8'/>
<id>urn:sha1:a4b51a9f83c6d359ff8fc0c66009283b6fdeeaf8</id>
<content type='text'>
atomic_t variables are currently used to implement reference
counters with the following properties:
 - counter is initialized to 1 using atomic_set()
 - a resource is freed upon counter reaching zero
 - once counter reaches zero, its further
   increments aren't allowed
 - counter schema uses basic atomic operations
   (set, inc, inc_not_zero, dec_and_test, etc.)

Such atomic variables should be converted to a newly provided
refcount_t type and API that prevents accidental counter overflows
and underflows. This is important since overflows and underflows
can lead to use-after-free situation and be exploitable.

The variable mlx5_cq.refcount is used as pure reference counter.
Convert it to refcount_t and fix up the operations.

Suggested-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: David Windsor &lt;dwindsor@gmail.com&gt;
Reviewed-by: Hans Liljestrand &lt;ishkamiel@gmail.com&gt;
Signed-off-by: Elena Reshetova &lt;elena.reshetova@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>IB/mlx5: Support 4k UAR for libmlx5</title>
<updated>2017-01-09T18:25:09Z</updated>
<author>
<name>Eli Cohen</name>
<email>eli@mellanox.com</email>
</author>
<published>2017-01-03T21:55:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=30aa60b3bd12bd79b5324b7b595bd3446ab24b52'/>
<id>urn:sha1:30aa60b3bd12bd79b5324b7b595bd3446ab24b52</id>
<content type='text'>
Add fields to structs to convey to kernel an indication whether the
library supports multi UARs per page and return to the library the size
of a UAR based on the queried value.

Signed-off-by: Eli Cohen &lt;eli@mellanox.com&gt;
Reviewed-by: Matan Barak &lt;matanb@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
</content>
</entry>
<entry>
<title>IB/mlx5: Use blue flame register allocator in mlx5_ib</title>
<updated>2017-01-09T18:25:08Z</updated>
<author>
<name>Eli Cohen</name>
<email>eli@mellanox.com</email>
</author>
<published>2017-01-03T21:55:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5fe9dec0d045437e48f112b8fa705197bd7bc3c0'/>
<id>urn:sha1:5fe9dec0d045437e48f112b8fa705197bd7bc3c0</id>
<content type='text'>
Make use of the blue flame registers allocator at mlx5_ib. Since blue
flame was not really supported we remove all the code that is related to
blue flame and we let all consumers to use the same blue flame register.
Once blue flame is supported we will add the code. As part of this patch
we also move the definition of struct mlx5_bf to mlx5_ib.h as it is only
used by mlx5_ib.

Signed-off-by: Eli Cohen &lt;eli@mellanox.com&gt;
Reviewed-by: Matan Barak &lt;matanb@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
</content>
</entry>
<entry>
<title>{net,IB}/mlx5: CQ commands via mlx5 ifc</title>
<updated>2016-08-14T11:39:15Z</updated>
<author>
<name>Saeed Mahameed</name>
<email>saeedm@mellanox.com</email>
</author>
<published>2016-07-15T23:33:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=278277866334e515141dde7c8ac143e15c0a767f'/>
<id>urn:sha1:278277866334e515141dde7c8ac143e15c0a767f</id>
<content type='text'>
Remove old representation of manually created CQ commands layout,
and use mlx5_ifc canonical structures and defines.

Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/mlx5: Reset flow support for IB kernel ULPs</title>
<updated>2016-06-23T15:02:45Z</updated>
<author>
<name>Maor Gottlieb</name>
<email>maorg@mellanox.com</email>
</author>
<published>2016-06-17T12:01:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=89ea94a7b6c40eb423c144aef1caceebaff79c8d'/>
<id>urn:sha1:89ea94a7b6c40eb423c144aef1caceebaff79c8d</id>
<content type='text'>
The driver exposes interfaces that directly relate to HW state.
Upon fatal error, consumers of these interfaces (ULPs) that rely
on completion of all their posted work-request could hang, thereby
introducing dependencies in shutdown order. To prevent this from
happening, we manage the relevant resources (CQs, QPs) that are used
by the device. Upon a fatal error, we now generate simulated
completions for outstanding WQEs that were not completed at the
time the HW was reset.

It includes invoking the completion event handler for all involved
CQs so that the ULPs will poll those CQs. When polled we return
simulated CQEs with IB_WC_WR_FLUSH_ERR return code enabling ULPs
to clean up their  resources and not wait forever for completions
upon receiving remove_one.

The above change requires an extra check in the data path to make
sure that when device is in error state, the simulated CQEs will
be returned and no further WQEs will be posted.

Signed-off-by: Maor Gottlieb &lt;maorg@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>net/mlx5_core: Use tasklet for user-space CQ completion events</title>
<updated>2016-05-18T14:45:49Z</updated>
<author>
<name>Matan Barak</name>
<email>matanb@mellanox.com</email>
</author>
<published>2016-04-17T14:08:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=94c6825e0ff75829207af6246782811b7c7af2c0'/>
<id>urn:sha1:94c6825e0ff75829207af6246782811b7c7af2c0</id>
<content type='text'>
Previously, we've fired all our completion callbacks straight from
our ISR.

Some of those callbacks were lightweight (for example, mlx5 Ethernet
napi callbacks), but some of them did more work (for example,
the user-space RDMA stack uverbs' completion handler). Besides that,
doing more than the minimal work in ISR is generally considered wrong,
it could even lead to a hard lockup of the system. Since when a lot
of completion events are generated by the hardware, the loop over
those events could be so long, that we'll get into a hard lockup by
the system watchdog.

In order to avoid that, add a new way of invoking completion events
callbacks. In the interrupt itself, we add the CQs which receive
completion event to a per-EQ list and schedule a tasklet. In the
tasklet context we loop over all the CQs in the list and invoke the
user callback.

Signed-off-by: Matan Barak &lt;matanb@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>net/mlx5_core: Fix trimming down IRQ number</title>
<updated>2016-01-17T17:08:04Z</updated>
<author>
<name>Doron Tsur</name>
<email>doront@mellanox.com</email>
</author>
<published>2016-01-17T09:25:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0b6e26ce89391327d955a756a7823272238eb867'/>
<id>urn:sha1:0b6e26ce89391327d955a756a7823272238eb867</id>
<content type='text'>
With several ConnectX-4 cards installed on a server, one may receive
irqn &gt; 255 from the kernel API, which we mistakenly trim to 8bit.

This causes EQ creation failure with the following stack trace:
[&lt;ffffffff812a11f4&gt;] dump_stack+0x48/0x64
[&lt;ffffffff810ace21&gt;] __setup_irq+0x3a1/0x4f0
[&lt;ffffffff810ad7e0&gt;] request_threaded_irq+0x120/0x180
[&lt;ffffffffa0923660&gt;] ? mlx5_eq_int+0x450/0x450 [mlx5_core]
[&lt;ffffffffa0922f64&gt;] mlx5_create_map_eq+0x1e4/0x2b0 [mlx5_core]
[&lt;ffffffffa091de01&gt;] alloc_comp_eqs+0xb1/0x180 [mlx5_core]
[&lt;ffffffffa091ea99&gt;] mlx5_dev_init+0x5e9/0x6e0 [mlx5_core]
[&lt;ffffffffa091ec29&gt;] init_one+0x99/0x1c0 [mlx5_core]
[&lt;ffffffff812e2afc&gt;] local_pci_probe+0x4c/0xa0

Fixing it by changing of the irqn type from u8 to unsigned int to
support values &gt; 255

Fixes: 61d0e73e0a5a ('net/mlx5_core: Use the the real irqn in eq-&gt;irqn')
Reported-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: Doron Tsur &lt;doront@mellanox.com&gt;
Signed-off-by: Matan Barak &lt;matanb@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
