<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/infiniband, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-07-26T07:13:04Z</updated>
<entry>
<title>IB/mlx5: Report correctly tag matching rendezvous capability</title>
<updated>2019-07-26T07:13:04Z</updated>
<author>
<name>Danit Goldberg</name>
<email>danitg@mellanox.com</email>
</author>
<published>2019-07-05T16:21:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7211b04064474ae016c52e8b068a212c815f94ca'/>
<id>urn:sha1:7211b04064474ae016c52e8b068a212c815f94ca</id>
<content type='text'>
commit 89705e92700170888236555fe91b45e4c1bb0985 upstream.

Userspace expects the IB_TM_CAP_RC bit to indicate that the device
supports RC transport tag matching with rendezvous offload. However the
firmware splits this into two capabilities for eager and rendezvous tag
matching.

Only if the FW supports both modes should userspace be told the tag
matching capability is available.

Cc: &lt;stable@vger.kernel.org&gt; # 4.13
Fixes: eb761894351d ("IB/mlx5: Fill XRQ capabilities")
Signed-off-by: Danit Goldberg &lt;danitg@mellanox.com&gt;
Reviewed-by: Yishai Hadas &lt;yishaih@mellanox.com&gt;
Reviewed-by: Artemy Kovalyov &lt;artemyko@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>RDMA/srp: Accept again source addresses that do not have a port number</title>
<updated>2019-07-26T07:13:03Z</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2019-05-29T16:38:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2cb0539095b4cce84110f3e210f421176f6bb62b'/>
<id>urn:sha1:2cb0539095b4cce84110f3e210f421176f6bb62b</id>
<content type='text'>
commit bcef5b7215681250c4bf8961dfe15e9e4fef97d0 upstream.

The function srp_parse_in() is used both for parsing source address
specifications and for target address specifications. Target addresses
must have a port number. Having to specify a port number for source
addresses is inconvenient. Make sure that srp_parse_in() supports again
parsing addresses with no port number.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: c62adb7def71 ("IB/srp: Fix IPv6 address parsing")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipoib: correcly show a VF hardware address</title>
<updated>2019-07-26T07:12:37Z</updated>
<author>
<name>Denis Kirjanov</name>
<email>kda@linux-powerpc.org</email>
</author>
<published>2019-06-17T08:53:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c545bda33b97b0c88c621f3488faedb7a7d73932'/>
<id>urn:sha1:c545bda33b97b0c88c621f3488faedb7a7d73932</id>
<content type='text'>
[ Upstream commit 64d701c608fea362881e823b666327f5d28d7ffd ]

in the case of IPoIB with SRIOV enabled hardware
ip link show command incorrecly prints
0 instead of a VF hardware address.

Before:
11: ib1: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
    link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state disable,
trust off, query_rss off
...
After:
11: ib1: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
    link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    vf 0     link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
checking off, link-state disable, trust off, query_rss off

v1-&gt;v2: just copy an address without modifing ifla_vf_mac
v2-&gt;v3: update the changelog

Signed-off-by: Denis Kirjanov &lt;kda@linux-powerpc.org&gt;
Acked-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/hfi1: Handle port down properly in pio</title>
<updated>2019-07-14T06:09:44Z</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@intel.com</email>
</author>
<published>2019-06-14T16:33:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e62ebc063f5ee8cfed2a799c43db954a9964677d'/>
<id>urn:sha1:e62ebc063f5ee8cfed2a799c43db954a9964677d</id>
<content type='text'>
[ Upstream commit 942a899335707fc9cfc97cb382a60734b2ff4e03 ]

The call to sc_buffer_alloc currently returns NULL (no buffer) or
a buffer descriptor.

There is a third case when the port is down.  Currently that
returns NULL and this prevents the caller from properly handling the
sc_buffer_alloc() failure.  A verbs code link test after the call is
racy so the indication needs to come from the state check inside the allocation
routine to be valid.

Fix by encoding the ECOMM failure like SDMA.   IS_ERR_OR_NULL() tests
are added at all call sites.  For verbs send, this needs to treat any
error by returning a completion without any MMIO copy.

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/hfi1: Handle wakeup of orphaned QPs for pio</title>
<updated>2019-07-14T06:09:44Z</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@intel.com</email>
</author>
<published>2019-06-14T16:33:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d19a1a9c4083e2b9015e7a1a151e9661ba5c47d5'/>
<id>urn:sha1:d19a1a9c4083e2b9015e7a1a151e9661ba5c47d5</id>
<content type='text'>
[ Upstream commit 099a884ba4c00145cef283d36e050726311c2e95 ]

Once a send context is taken down due to a link failure, any QPs waiting
for pio credits will stay on the waitlist indefinitely.

Fix by wakeing up all QPs linked to piowait list.

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/hfi1: Wakeup QPs orphaned on wait list after flush</title>
<updated>2019-07-14T06:09:44Z</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@intel.com</email>
</author>
<published>2019-06-14T16:32:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c7a79b35dd816c47745c021953cdc92c78c1d6b8'/>
<id>urn:sha1:c7a79b35dd816c47745c021953cdc92c78c1d6b8</id>
<content type='text'>
[ Upstream commit f972775b1cc0441ae22c9f8d06dd16b118463632 ]

Once an SDMA engine is taken down due to a link failure, any waiting QPs
that do not have outstanding descriptors in the ring will stay
on the dmawait list as long as the port is down.

Since there is no timer running, they will stay there for a long time.

The fix is to wake up all iowaits linked to dmawait. The send engine
will build and post packets that get flushed back.

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Kaike Wan &lt;kaike.wan@intel.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/hfi1: Use aborts to trigger RC throttling</title>
<updated>2019-07-14T06:09:44Z</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@intel.com</email>
</author>
<published>2019-06-14T16:32:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=01514e2d6ea9c79f40697b570a0a4648a2d008eb'/>
<id>urn:sha1:01514e2d6ea9c79f40697b570a0a4648a2d008eb</id>
<content type='text'>
[ Upstream commit 4bb02e9572af1383038d83ad196d7166c515f2ee ]

SDMA and pio flushes will cause a lot of packets to be transmitted
after a link has gone down, using a lot of CPU to retransmit
packets.

Fix for RC QPs by recognizing the flush status and:
- Forcing a timer start
- Putting the QP into a "send one" mode

Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Kaike Wan &lt;kaike.wan@intel.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/hfi1: Create inline to get extended headers</title>
<updated>2019-07-14T06:09:44Z</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@intel.com</email>
</author>
<published>2019-06-14T16:32:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=339d51e3723bb049728d4d9d7c61dd836e7a3263'/>
<id>urn:sha1:339d51e3723bb049728d4d9d7c61dd836e7a3263</id>
<content type='text'>
[ Upstream commit 9755f72496664eec70bc804104118b5797b6bf63 ]

This paves the way for another patch that reacts to a
flush sdma completion for RC.

Fixes: 81cd3891f021 ("IB/hfi1: Add support for 16B Management Packets")
Reviewed-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA: Directly cast the sockaddr union to sockaddr</title>
<updated>2019-07-03T11:13:44Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@mellanox.com</email>
</author>
<published>2019-05-13T00:57:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=993a0821eb5b810bff67152a8005e1107f07a69d'/>
<id>urn:sha1:993a0821eb5b810bff67152a8005e1107f07a69d</id>
<content type='text'>
commit 641114d2af312d39ca9bbc2369d18a5823da51c6 upstream.

gcc 9 now does allocation size tracking and thinks that passing the member
of a union and then accessing beyond that member's bounds is an overflow.

Instead of using the union member, use the entire union with a cast to
get to the sockaddr. gcc will now know that the memory extends the full
size of the union.

Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/hfi1: Validate page aligned for a given virtual address</title>
<updated>2019-06-25T03:34:49Z</updated>
<author>
<name>Kamenee Arumugam</name>
<email>kamenee.arumugam@intel.com</email>
</author>
<published>2019-05-24T15:45:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f17c4c68e9b736f24d225f6c9218abe00a6e5d97'/>
<id>urn:sha1:f17c4c68e9b736f24d225f6c9218abe00a6e5d97</id>
<content type='text'>
[ Upstream commit 97736f36dbebf2cda2799db3b54717ba5b388255 ]

User applications can register memory regions for TID buffers that are not
aligned on page boundaries. Hfi1 is expected to pin those pages in memory
and cache the pages with mmu_rb. The rb tree will fail to insert pages
that are not aligned correctly.

Validate whether a given virtual address is page aligned before pinning.

Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
Reviewed-by: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Signed-off-by: Kamenee Arumugam &lt;kamenee.arumugam@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
