<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/nvme/target, branch v5.6.17</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.6.17</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.6.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-04-17T14:13:28+00:00</updated>
<entry>
<title>nvme-fc: Revert "add module to ops template to allow module references"</title>
<updated>2020-04-17T14:13:28+00:00</updated>
<author>
<name>James Smart</name>
<email>jsmart2021@gmail.com</email>
</author>
<published>2020-04-03T14:33:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a192f91a9e915600599ed13d6a92e16120f97647'/>
<id>urn:sha1:a192f91a9e915600599ed13d6a92e16120f97647</id>
<content type='text'>
commit 8c5c660529209a0e324c1c1a35ce3f83d67a2aa5 upstream.

The original patch was to resolve the lldd being able to be unloaded
while being used to talk to the boot device of the system. However, the
end result of the original patch is that any driver unload while a nvme
controller is live via the lldd is now being prohibited. Given the module
reference, the module teardown routine can't be called, thus there's no
way, other than manual actions to terminate the controllers.

Fixes: 863fbae929c7 ("nvme_fc: add module to ops template to allow module references")
Cc: &lt;stable@vger.kernel.org&gt; # v5.4+
Signed-off-by: James Smart &lt;jsmart2021@gmail.com&gt;
Reviewed-by: Himanshu Madhani &lt;himanshu.madhani@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nvmet-tcp: fix maxh2cdata icresp parameter</title>
<updated>2020-04-17T14:13:28+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2020-02-26T00:42:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f7c91cee97b4757b5f7cfad1f892690e68f09d31'/>
<id>urn:sha1:f7c91cee97b4757b5f7cfad1f892690e68f09d31</id>
<content type='text'>
commit 9cda34e37489244a8c8628617e24b2dbc8a8edad upstream.

MAXH2CDATA is not zero based. Also no reason to limit ourselves to
1M transfers as we can do more easily. Make this an arbitrary limit
of 16M.

Reported-by: Wenhua Liu &lt;liuw@vmware.com&gt;
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nvmet-tcp: set MSG_MORE only if we actually have more to send</title>
<updated>2020-03-20T19:37:53+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2020-03-12T23:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98fd5c723730f560e5bea919a64ac5b83d45eb72'/>
<id>urn:sha1:98fd5c723730f560e5bea919a64ac5b83d45eb72</id>
<content type='text'>
When we send PDU data, we want to optimize the tcp stack
operation if we have more data to send. So when we set MSG_MORE
when:
- We have more fragments coming in the batch, or
- We have a more data to send in this PDU
- We don't have a data digest trailer
- We optimize with the SUCCESS flag and omit the NVMe completion
  (used if sq_head pointer update is disabled)

This addresses a regression in QD=1 with SUCCESS flag optimization
as we unconditionally set MSG_MORE when we didn't actually have
more data to send.

Fixes: 70583295388a ("nvmet-tcp: implement C2HData SUCCESS optimization")
Reported-by: Mark Wunderlich &lt;mark.wunderlich@intel.com&gt;
Tested-by: Mark Wunderlich &lt;mark.wunderlich@intel.com&gt;
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: update AEN list and array at one place</title>
<updated>2020-02-04T16:56:10+00:00</updated>
<author>
<name>Daniel Wagner</name>
<email>dwagner@suse.de</email>
</author>
<published>2020-01-30T18:29:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f5be6a4ff7b3f8bf3db15f904e3e76797a43d9a'/>
<id>urn:sha1:0f5be6a4ff7b3f8bf3db15f904e3e76797a43d9a</id>
<content type='text'>
All async events are enqueued via nvmet_add_async_event() which
updates the ctrl-&gt;async_event_cmds[] array and additionally an struct
nvmet_async_event is added to the ctrl-&gt;async_events list.

Under normal operations the nvmet_async_event_work() updates again
the ctrl-&gt;async_event_cmds and removes the corresponding struct
nvmet_async_event from the list again. Though nvmet_sq_destroy() could
be called which calls nvmet_async_events_free() which only updates the
ctrl-&gt;async_event_cmds[] array.

Add new functions nvmet_async_events_process() and
nvmet_async_events_free() to process async events, update an array and
the list.

When we destroy submission queue after clearing the aen present on
the ctrl-&gt;async list we also loop over ctrl-&gt;async_event_cmds[] for
any requests posted by the host for which we don't have the AEN in
the ctrl-&gt;async_events list by calling nvmet_async_event_process()
and nvmet_async_events_free().

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Daniel Wagner &lt;dwagner@suse.de&gt;
[chaitanya.kulkarni@wdc.com
 * Loop over and clear out outstanding requests
 * Update changelog
]
Signed-off-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: Fix controller use after free</title>
<updated>2020-02-04T16:13:09+00:00</updated>
<author>
<name>Israel Rukshin</name>
<email>israelr@mellanox.com</email>
</author>
<published>2020-02-04T12:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1a3f540d63152b8db0a12de508bfa03776217d83'/>
<id>urn:sha1:1a3f540d63152b8db0a12de508bfa03776217d83</id>
<content type='text'>
After nvmet_install_queue() sets sq-&gt;ctrl calling to nvmet_sq_destroy()
reduces the controller refcount. In case nvmet_install_queue() fails,
calling to nvmet_ctrl_put() is done twice (at nvmet_sq_destroy and
nvmet_execute_io_connect/nvmet_execute_admin_connect) instead of once for
the queue which leads to use after free of the controller. Fix this by set
NULL at sq-&gt;ctrl in case of a failure at nvmet_install_queue().

The bug leads to the following Call Trace:

[65857.994862] refcount_t: underflow; use-after-free.
[65858.108304] Workqueue: events nvmet_rdma_release_queue_work [nvmet_rdma]
[65858.115557] RIP: 0010:refcount_warn_saturate+0xe5/0xf0
[65858.208141] Call Trace:
[65858.211203]  nvmet_sq_destroy+0xe1/0xf0 [nvmet]
[65858.216383]  nvmet_rdma_release_queue_work+0x37/0xf0 [nvmet_rdma]
[65858.223117]  process_one_work+0x167/0x370
[65858.227776]  worker_thread+0x49/0x3e0
[65858.232089]  kthread+0xf5/0x130
[65858.235895]  ? max_active_store+0x80/0x80
[65858.240504]  ? kthread_bind+0x10/0x10
[65858.244832]  ret_from_fork+0x1f/0x30
[65858.249074] ---[ end trace f82d59250b54beb7 ]---

Fixes: bb1cc74790eb ("nvmet: implement valid sqhd values in completions")
Fixes: 1672ddb8d691 ("nvmet: Add install_queue callout")
Signed-off-by: Israel Rukshin &lt;israelr@mellanox.com&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: Fix error print message at nvmet_install_queue function</title>
<updated>2020-02-04T16:13:06+00:00</updated>
<author>
<name>Israel Rukshin</name>
<email>israelr@mellanox.com</email>
</author>
<published>2020-02-04T12:38:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b87a2b795d66be7b54779848ef0f3901c5e46fc'/>
<id>urn:sha1:0b87a2b795d66be7b54779848ef0f3901c5e46fc</id>
<content type='text'>
Place the arguments in the correct order.

Fixes: 1672ddb8d691 ("nvmet: Add install_queue callout")
Signed-off-by: Israel Rukshin &lt;israelr@mellanox.com&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: fix dsm failure when payload does not match sgl descriptor</title>
<updated>2020-02-03T18:00:24+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2020-01-27T07:23:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b716e6889c95f64ba32af492461f6cc9341f3f05'/>
<id>urn:sha1:b716e6889c95f64ba32af492461f6cc9341f3f05</id>
<content type='text'>
The host is allowed to pass the controller an sgl describing a buffer
that is larger than the dsm payload itself, allow it when executing
dsm.

Reported-by: Dakshaja Uppalapati &lt;dakshaja@chelsio.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;,
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: Pass lockdep expression to RCU lists</title>
<updated>2020-02-03T18:00:24+00:00</updated>
<author>
<name>Amol Grover</name>
<email>frextrite@gmail.com</email>
</author>
<published>2020-01-11T07:38:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4ac76436a6d07dec1c3c766f234aa787a16e8f65'/>
<id>urn:sha1:4ac76436a6d07dec1c3c766f234aa787a16e8f65</id>
<content type='text'>
ctrl-&gt;subsys-&gt;namespaces and subsys-&gt;namespaces are traversed with
list_for_each_entry_rcu outside an RCU read-side critical section but
under the protection of ctrl-&gt;subsys-&gt;lock and subsys-&gt;lock respectively.

Hence, add the corresponding lockdep expression to the list traversal
primitive to silence false-positive lockdep warnings, and harden RCU
lists.

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Reviewed-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Signed-off-by: Amol Grover &lt;frextrite@gmail.com&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: fix per feat data len for get_feature</title>
<updated>2020-01-10T15:55:50+00:00</updated>
<author>
<name>Amit Engel</name>
<email>amit.engel@dell.com</email>
</author>
<published>2020-01-07T16:47:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e17016f6dcb047f91a8fc9f46bbf81a21d15ca73'/>
<id>urn:sha1:e17016f6dcb047f91a8fc9f46bbf81a21d15ca73</id>
<content type='text'>
The existing implementation for the get_feature admin-cmd does not
use per-feature data len. This patch introduces a new helper function
nvmet_feat_data_len(), which is used to calculate per feature data len.
Right now we only set data len for fid 0x81 (NVME_FEAT_HOST_ID).

Fixes: commit e9061c397839 ("nvmet: Remove the data_len field from the nvmet_req struct")

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Amit Engel &lt;amit.engel@dell.com&gt;
[endiness, naming, and kernel style fixes]
Signed-off-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>nvme_fc: add module to ops template to allow module references</title>
<updated>2019-11-26T17:48:27+00:00</updated>
<author>
<name>James Smart</name>
<email>jsmart2021@gmail.com</email>
</author>
<published>2019-11-14T23:15:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=863fbae929c7a5b64e96b8a3ffb34a29eefb9f8f'/>
<id>urn:sha1:863fbae929c7a5b64e96b8a3ffb34a29eefb9f8f</id>
<content type='text'>
In nvme-fc: it's possible to have connected active controllers
and as no references are taken on the LLDD, the LLDD can be
unloaded.  The controller would enter a reconnect state and as
long as the LLDD resumed within the reconnect timeout, the
controller would resume.  But if a namespace on the controller
is the root device, allowing the driver to unload can be problematic.
To reload the driver, it may require new io to the boot device,
and as it's no longer connected we get into a catch-22 that
eventually fails, and the system locks up.

Fix this issue by taking a module reference for every connected
controller (which is what the core layer did to the transport
module). Reference is cleared when the controller is removed.

Acked-by: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: James Smart &lt;jsmart2021@gmail.com&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
</feed>
