<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/infiniband, branch linux-4.0.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.0.y</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.0.y'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2015-07-21T17:10:14+00:00</updated>
<entry>
<title>IB/srp: Fix reconnection failure handling</title>
<updated>2015-07-21T17:10:14+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-05-18T11:24:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f38f2f4816e8ce4ec41b39b024d97964be55f5ca'/>
<id>urn:sha1:f38f2f4816e8ce4ec41b39b024d97964be55f5ca</id>
<content type='text'>
commit a44074f14ba1ea0747ea737026eb929b81993dc3 upstream.

Although it is possible to let SRP I/O continue if a reconnect
results in a reduction of the number of channels, the current
code does not handle this scenario correctly. Instead of making
the reconnect code more complex, consider this as a reconnection
failure.

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Sebastian Parschauer &lt;sebastian.riemer@profitbricks.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/srp: Fix connection state tracking</title>
<updated>2015-07-21T17:10:14+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-05-18T11:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4b7d950141dcd06b3b53ffd7925cebb32806ffed'/>
<id>urn:sha1:4b7d950141dcd06b3b53ffd7925cebb32806ffed</id>
<content type='text'>
commit c014c8cd31b161e12deb81c0f7f477811bd1eddc upstream.

Reception of a DREQ message only causes the state of a single
channel to change. Hence move the 'connected' member variable
from the target to the channel data structure. This patch
avoids that following false positive warning can be reported
by srp_destroy_qp():

WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:617 srp_destroy_qp+0xa6/0x120 [ib_srp]()
Call Trace:
[&lt;ffffffff8106e10f&gt;] warn_slowpath_common+0x7f/0xc0
[&lt;ffffffff8106e16a&gt;] warn_slowpath_null+0x1a/0x20
[&lt;ffffffffa0440226&gt;] srp_destroy_qp+0xa6/0x120 [ib_srp]
[&lt;ffffffffa0440322&gt;] srp_free_ch_ib+0x82/0x1e0 [ib_srp]
[&lt;ffffffffa044408b&gt;] srp_create_target+0x7ab/0x998 [ib_srp]
[&lt;ffffffff81346f60&gt;] dev_attr_store+0x20/0x30
[&lt;ffffffff811dd90f&gt;] sysfs_write_file+0xef/0x170
[&lt;ffffffff8116d248&gt;] vfs_write+0xc8/0x190
[&lt;ffffffff8116d411&gt;] sys_write+0x51/0x90

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Sebastian Parschauer &lt;sebastian.riemer@profitbricks.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/srp: Fix a connection setup race</title>
<updated>2015-07-21T17:10:14+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-05-18T11:23:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f1a9203f14887ad1297645cef8d23b4db93955ae'/>
<id>urn:sha1:f1a9203f14887ad1297645cef8d23b4db93955ae</id>
<content type='text'>
commit 8de9fe3a1d4ac8c3e4953fa4b7d81f863f5196ad upstream.

Avoid that receiving a DREQ while RDMA channels are being
established causes target-&gt;qp_in_error to be reset.

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Sebastian Parschauer &lt;sebastian.riemer@profitbricks.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/srp: Remove an extraneous scsi_host_put() from an error path</title>
<updated>2015-07-21T17:10:14+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-05-18T11:23:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce5f8d2f983b7822697089b15794326bb07ef303'/>
<id>urn:sha1:ce5f8d2f983b7822697089b15794326bb07ef303</id>
<content type='text'>
commit fb49c8bbaae70b14fea2b4590a90a21539f88526 upstream.

Fix a scsi_get_host() / scsi_host_put() imbalance in the error
path of srp_create_target(). See also patch "IB/srp: Avoid that
I/O hangs due to a cable pull during LUN scanning" (commit ID
34aa654ecb8e).

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Sebastian Parschauer &lt;sebastian.riemer@profitbricks.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iser-target: release stale iser connections</title>
<updated>2015-07-21T17:10:13+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2015-06-04T16:49:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6db453864ce75b51e3dada663befe32014c54c88'/>
<id>urn:sha1:6db453864ce75b51e3dada663befe32014c54c88</id>
<content type='text'>
commit 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a upstream.

When receiving a new iser connect request we serialize
the pending requests by adding the newly created iser connection
to the np accept list and let the login thread process the connect
request one by one (np_accept_wait).

In case we received a disconnect request before the iser_conn
has begun processing (still linked in np_accept_list) we should
detach it from the list and clean it up and not have the login
thread process a stale connection. We do it only when the connection
state is not already terminating (initiator driven disconnect) as
this might lead us to access np_accept_mutex after the np was released
in live shutdown scenarios.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Jenny Falkovich &lt;jennyf@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iser-target: Fix possible use-after-free</title>
<updated>2015-06-29T19:29:07+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2015-06-04T16:49:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ad57c140b86de638bc841a913fbbd87b4204abf2'/>
<id>urn:sha1:ad57c140b86de638bc841a913fbbd87b4204abf2</id>
<content type='text'>
commit 524630d5824c7a75aab568c6bd1423fd748cd3bb upstream.

iser connection termination process happens in 2 stages:
- isert_wait_conn:
  - resumes rdma disconnect
  - wait for session commands
  - wait for flush completions (post a marked wr to signal we are done)
  - wait for logout completion
  - queue work for connection cleanup (depends on disconnected/timewait
    events)
- isert_free_conn
  - last reference put on the connection

In case we are terminating during IOs, we might be posting send/recv
requests after we posted the last work request which might lead
to a use-after-free condition in isert_handle_wc.
After we posted the last wr in isert_wait_conn we are guaranteed that
no successful completions will follow (meaning no new work request posts
may happen) but other flush errors might still come. So before we
put the last reference on the connection, we repeat the process of
posting a marked work request (isert_wait4flush) in order to make sure all
pending completions were flushed.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Jenny Falkovich &lt;jennyf@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iser-target: Fix variable-length response error completion</title>
<updated>2015-06-29T19:29:07+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2015-06-04T16:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b4385f224870229f040ed5b1981c6b5e676b8a12'/>
<id>urn:sha1:b4385f224870229f040ed5b1981c6b5e676b8a12</id>
<content type='text'>
commit 9253e667ab50fd4611a60e1cdd6a6e05a1d91cf1 upstream.

Since commit "2426bd456a6 target: Report correct response ..."
we might get a command with data_size that does not fit to
the number of allocated data sg elements. Given that we rely on
cmd t_data_nents which might be different than the data_size,
we sometimes receive local length error completion. The correct
approach would be to take the command data_size into account when
constructing the ib sg_list.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Jenny Falkovich &lt;jennyf@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>RDMA/core: Fix for parsing netlink string attribute</title>
<updated>2015-06-06T15:20:58+00:00</updated>
<author>
<name>Tatyana Nikolova</name>
<email>Tatyana.E.Nikolova@intel.com</email>
</author>
<published>2015-05-08T21:36:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=61d25be9407da5fa1fb7b5cf30fac1c1a9a37ed8'/>
<id>urn:sha1:61d25be9407da5fa1fb7b5cf30fac1c1a9a37ed8</id>
<content type='text'>
commit ec04847c0c5b471bab2dacceadfdb803a9d1a2ea upstream.

The string iwpm_ulib_name is recorded in a nlmsg as a netlink attribute.
Without this fix parsing of the nlmsg by the userspace port mapper service fails
because of unknown attribute length, causing the port mapper service not to
register the client, which has sent the nlmsg.

Signed-off-by: Tatyana Nikolova &lt;tatyana.e.nikolova@intel.com&gt;
Reviewed-By: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>RDMA/CMA: Canonize IPv4 on IPV6 sockets properly</title>
<updated>2015-05-17T16:55:06+00:00</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgunthorpe@obsidianresearch.com</email>
</author>
<published>2015-04-20T20:01:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6a07da8c28e46379bf7eec6f0f8cdc68ebe627c7'/>
<id>urn:sha1:6a07da8c28e46379bf7eec6f0f8cdc68ebe627c7</id>
<content type='text'>
commit 285214409a9e5fceba2215461b4682b6069d8e77 upstream.

When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to
canonize the address family to IPv4, but does not properly process
the listening sockaddr to get the listening port, and does not properly
set the address family of the canonized sockaddr.

Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")

Reported-By: Yotam Kenneth &lt;yotamke@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Tested-by: Haggai Eran &lt;haggaie@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/iser: Fix wrong calculation of protection buffer length</title>
<updated>2015-05-06T20:04:01+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2015-04-14T15:08:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6fb5785d6c07d834567ccf3f3ba2df9c3803b28b'/>
<id>urn:sha1:6fb5785d6c07d834567ccf3f3ba2df9c3803b28b</id>
<content type='text'>
commit a065fe6aa25ba6ba93c02dc13486131bb3c64d5f upstream.

This length miss-calculation may cause a silent data corruption
in the DIX case and cause the device to reference unmapped area.

Fixes: d77e65350f2d ('libiscsi, iser: Adjust data_length to include protection information')
Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
