<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/drivers/infiniband/sw/rxe, branch master</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=master</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2020-02-13T14:51:09+00:00</updated>
<entry>
<title>RDMA/rxe: Fix soft lockup problem due to using tasklets in softirq</title>
<updated>2020-02-13T14:51:09+00:00</updated>
<author>
<name>Zhu Yanjun</name>
<email>yanjunz@mellanox.com</email>
</author>
<published>2020-02-12T07:26:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=8ac0e6641c7ca14833a2a8c6f13d8e0a435e535c'/>
<id>urn:sha1:8ac0e6641c7ca14833a2a8c6f13d8e0a435e535c</id>
<content type='text'>
When run stress tests with RXE, the following Call Traces often occur

  watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [swapper/2:0]
  ...
  Call Trace:
  &lt;IRQ&gt;
  create_object+0x3f/0x3b0
  kmem_cache_alloc_node_trace+0x129/0x2d0
  __kmalloc_reserve.isra.52+0x2e/0x80
  __alloc_skb+0x83/0x270
  rxe_init_packet+0x99/0x150 [rdma_rxe]
  rxe_requester+0x34e/0x11a0 [rdma_rxe]
  rxe_do_task+0x85/0xf0 [rdma_rxe]
  tasklet_action_common.isra.21+0xeb/0x100
  __do_softirq+0xd0/0x298
  irq_exit+0xc5/0xd0
  smp_apic_timer_interrupt+0x68/0x120
  apic_timer_interrupt+0xf/0x20
  &lt;/IRQ&gt;
  ...

The root cause is that tasklet is actually a softirq. In a tasklet
handler, another softirq handler is triggered. Usually these softirq
handlers run on the same cpu core. So this will cause "soft lockup Bug".

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Link: https://lore.kernel.org/r/20200212072635.682689-8-leon@kernel.org
Signed-off-by: Zhu Yanjun &lt;yanjunz@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'rds-odp-for-5.5' into rdma.git for-next</title>
<updated>2020-01-21T13:55:04+00:00</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@mellanox.com</email>
</author>
<published>2020-01-21T13:55:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=e8b3a426fb4a9e2856a69b6e19de044c7416c316'/>
<id>urn:sha1:e8b3a426fb4a9e2856a69b6e19de044c7416c316</id>
<content type='text'>
From https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma

Leon Romanovsky says:

====================
Use ODP MRs for kernel ULPs

The following series extends MR creation routines to allow creation of
user MRs through kernel ULPs as a proxy. The immediate use case is to
allow RDS to work over FS-DAX, which requires ODP (on-demand-paging)
MRs to be created and such MRs were not possible to create prior this
series.

The first part of this patchset extends RDMA to have special verb
ib_reg_user_mr(). The common use case that uses this function is a
userspace application that allocates memory for HCA access but the
responsibility to register the memory at the HCA is on an kernel ULP.
This ULP acts as an agent for the userspace application.

The second part provides advise MR functionality for ULPs. This is
integral part of ODP flows and used to trigger pagefaults in advance
to prepare memory before running working set.

The third part is actual user of those in-kernel APIs.
====================

* tag 'rds-odp-for-5.5':
  net/rds: Use prefetch for On-Demand-Paging MR
  net/rds: Handle ODP mr registration/unregistration
  net/rds: Detect need of On-Demand-Paging memory registration
  RDMA/mlx5: Fix handling of IOVA != user_va in ODP paths
  IB/mlx5: Mask out unsupported ODP capabilities for kernel QPs
  RDMA/mlx5: Don't fake udata for kernel path
  IB/mlx5: Add ODP WQE handlers for kernel QPs
  IB/core: Add interface to advise_mr for kernel users
  IB/core: Introduce ib_reg_user_mr
  IB: Allow calls to ib_umem_get from kernel ULPs

Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>IB: Allow calls to ib_umem_get from kernel ULPs</title>
<updated>2020-01-16T14:14:28+00:00</updated>
<author>
<name>Moni Shoua</name>
<email>monis@mellanox.com</email>
</author>
<published>2020-01-15T12:43:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=c320e527e1548305f31d95ec405140b04aed25f5'/>
<id>urn:sha1:c320e527e1548305f31d95ec405140b04aed25f5</id>
<content type='text'>
So far the assumption was that ib_umem_get() and ib_umem_odp_get()
are called from flows that start in UVERBS and therefore has a user
context. This assumption restricts flows that are initiated by ULPs
and need the service that ib_umem_get() provides.

This patch changes ib_umem_get() and ib_umem_odp_get() to get IB device
directly by relying on the fact that both UVERBS and ULPs sets that
field correctly.

Reviewed-by: Guy Levi &lt;guyle@mellanox.com&gt;
Signed-off-by: Moni Shoua &lt;monis@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/rxe: Compute the maximum sges and inline size based on the WQE size</title>
<updated>2020-01-15T20:36:41+00:00</updated>
<author>
<name>Rao Shoaib</name>
<email>rao.shoaib@oracle.com</email>
</author>
<published>2020-01-14T00:41:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=363824f92a9259b025f05ab038eb47224377f9e9'/>
<id>urn:sha1:363824f92a9259b025f05ab038eb47224377f9e9</id>
<content type='text'>
The SGE buffer size and max_inline data should be derived from the size of
the WQE. Each value individually sets the WQE size, so compute the actual
sizes based on the actual WQE size and configure the QP with the maximums.

Also fix the missing return of the actual maximum capability to the caller.

Link: https://lore.kernel.org/r/1578962480-17814-3-git-send-email-rao.shoaib@oracle.com
Signed-off-by: Rao Shoaib &lt;rao.shoaib@oracle.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>Introduce maximum WQE size to check limits</title>
<updated>2020-01-15T20:27:01+00:00</updated>
<author>
<name>Rao Shoaib</name>
<email>rao.shoaib@oracle.com</email>
</author>
<published>2020-01-14T00:41:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=4e8d683f11767dc6cd8eaac6b599928f343b4cdb'/>
<id>urn:sha1:4e8d683f11767dc6cd8eaac6b599928f343b4cdb</id>
<content type='text'>
Introduce maximum WQE size to impose limits on max SGE's and inline data

Link: https://lore.kernel.org/r/1578962480-17814-2-git-send-email-rao.shoaib@oracle.com
Signed-off-by: Rao Shoaib &lt;rao.shoaib@oracle.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/rxe: Fix error type of mmap_offset</title>
<updated>2020-01-03T23:43:51+00:00</updated>
<author>
<name>Jiewei Ke</name>
<email>kejiewei.cn@gmail.com</email>
</author>
<published>2019-12-27T11:36:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=6ca18d8927d468c763571f78c9a7387a69ffa020'/>
<id>urn:sha1:6ca18d8927d468c763571f78c9a7387a69ffa020</id>
<content type='text'>
The type of mmap_offset should be u64 instead of int to match the type of
mminfo.offset. If otherwise, after we create several thousands of CQs, it
will run into overflow issues.

Link: https://lore.kernel.org/r/20191227113613.5020-1-kejiewei.cn@gmail.com
Signed-off-by: Jiewei Ke &lt;kejiewei.cn@gmail.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>rxe: correctly calculate iCRC for unaligned payloads</title>
<updated>2019-12-09T18:55:26+00:00</updated>
<author>
<name>Steve Wise</name>
<email>larrystevenwise@gmail.com</email>
</author>
<published>2019-12-03T02:03:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=2030abddec6884aaf5892f5724c48fc340e6826f'/>
<id>urn:sha1:2030abddec6884aaf5892f5724c48fc340e6826f</id>
<content type='text'>
If RoCE PDUs being sent or received contain pad bytes, then the iCRC
is miscalculated, resulting in PDUs being emitted by RXE with an incorrect
iCRC, as well as ingress PDUs being dropped due to erroneously detecting
a bad iCRC in the PDU.  The fix is to include the pad bytes, if any,
in iCRC computations.

Note: This bug has caused broken on-the-wire compatibility with actual
hardware RoCE devices since the soft-RoCE driver was first put into the
mainstream kernel.  Fixing it will create an incompatibility with the
original soft-RoCE devices, but is necessary to be compatible with real
hardware devices.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: Steve Wise &lt;larrystevenwise@gmail.com&gt;
Link: https://lore.kernel.org/r/20191203020319.15036-2-larrystevenwise@gmail.com
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup</title>
<updated>2019-12-04T20:27:13+00:00</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2019-12-04T14:35:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=6c8991f41546c3c472503dff1ea9daaddf9331c2'/>
<id>urn:sha1:6c8991f41546c3c472503dff1ea9daaddf9331c2</id>
<content type='text'>
ipv6_stub uses the ip6_dst_lookup function to allow other modules to
perform IPv6 lookups. However, this function skips the XFRM layer
entirely.

All users of ipv6_stub-&gt;ip6_dst_lookup use ip_route_output_flow (via the
ip_route_output_key and ip_route_output helpers) for their IPv4 lookups,
which calls xfrm_lookup_route(). This patch fixes this inconsistent
behavior by switching the stub to ip6_dst_lookup_flow, which also calls
xfrm_lookup_route().

This requires some changes in all the callers, as these two functions
take different arguments and have different return types.

Fixes: 5f81bd2e5d80 ("ipv6: export a stub for IPv6 symbols used by vxlan")
Reported-by: Xiumei Mu &lt;xmu@redhat.com&gt;
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>IB/umem: remove the dmasync argument to ib_umem_get</title>
<updated>2019-11-17T14:37:00+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-11-13T07:32:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=72b894b09a96b741c92562709f6629310f2b34a1'/>
<id>urn:sha1:72b894b09a96b741c92562709f6629310f2b34a1</id>
<content type='text'>
The argument is always ignored, so remove it.

Link: https://lore.kernel.org/r/20191113073214.9514-3-hch@lst.de
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Acked-by: Michal Kalderon &lt;michal.kalderon@marvell.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
<entry>
<title>RDMA/rxe: Increase DMA max_segment_size parameter</title>
<updated>2019-10-28T17:52:03+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2019-10-25T22:58:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=97458fd510917f142c417245fa5701a892ce69d7'/>
<id>urn:sha1:97458fd510917f142c417245fa5701a892ce69d7</id>
<content type='text'>
Increase the DMA max_segment_size parameter from 64 KB to 2 GB.

Link: https://lore.kernel.org/r/20191025225830.257535-3-bvanassche@acm.org
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
</content>
</entry>
</feed>
