<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/nvme/host, branch linux-4.20.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-03-13T21:04:17+00:00</updated>
<entry>
<title>nvme-pci: add missing unlock for reset error</title>
<updated>2019-03-13T21:04:17+00:00</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2019-02-11T16:23:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=365e2f3a358a42c362177564d58433718cf58cda'/>
<id>urn:sha1:365e2f3a358a42c362177564d58433718cf58cda</id>
<content type='text'>
[ Upstream commit 4726bcf30fad37cc555cd9dcd6c73f2b2668c879 ]

The reset work holds a mutex to prevent races with removal modifying the
same resources, but was unlocking only on success. Unlock on failure
too.

Fixes: 5c959d73dba64 ("nvme-pci: fix rapid add remove sequence")
Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-pci: fix rapid add remove sequence</title>
<updated>2019-03-13T21:04:17+00:00</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2019-01-24T01:46:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c13a99fe8c6d9d5ff85f7a90dcca07a3cbd4a0ba'/>
<id>urn:sha1:c13a99fe8c6d9d5ff85f7a90dcca07a3cbd4a0ba</id>
<content type='text'>
[ Upstream commit 5c959d73dba6495ec01d04c206ee679d61ccb2b0 ]

A surprise removal may fail to tear down request queues if it is racing
with the initial asynchronous probe. If that happens, the remove path
won't see the queue resources to tear down, and the controller reset
path may create a new request queue on a removed device, but will not
be able to make forward progress, deadlocking the pci removal.

Protect setting up non-blocking resources from a shutdown by holding the
same mutex, and transition to the CONNECTING state after these resources
are initialized so the probe path may see the dead controller state
before dispatching new IO.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=202081
Reported-by: Alex Gagniuc &lt;Alex_Gagniuc@Dellteam.com&gt;
Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Tested-by: Alex Gagniuc &lt;mr.nuke.me@gmail.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: lock NS list changes while handling command effects</title>
<updated>2019-03-13T21:04:16+00:00</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2019-01-28T16:46:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6791cbc4f57215bb7de561e2ae1603a547b26149'/>
<id>urn:sha1:6791cbc4f57215bb7de561e2ae1603a547b26149</id>
<content type='text'>
[ Upstream commit e7ad43c3eda6a1690c4c3c341f95dc1c6898da83 ]

If a controller supports the NS Change Notification, the namespace
scan_work is automatically triggered after attaching a new namespace.

Occasionally the namespace scan_work may append the new namespace to the
list before the admin command effects handling is completed. The effects
handling unfreezes namespaces, but if it unfreezes the newly attached
namespace, its request_queue freeze depth will be off and we'll hit the
warning in blk_mq_unfreeze_queue().

On the next namespace add, we will fail to freeze that queue due to the
previous bad accounting and deadlock waiting for frozen.

Fix that by preventing scan work from altering the namespace list while
command effects handling needs to pair freeze with unfreeze.

Reported-by: Wen Xiong &lt;wenxiong@us.ibm.com&gt;
Tested-by: Wen Xiong &lt;wenxiong@us.ibm.com&gt;
Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Reviewed-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-multipath: drop optimization for static ANA group IDs</title>
<updated>2019-03-05T16:59:41+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2019-01-09T08:45:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0581ea5469a6440eac207b225145bb6b45f43756'/>
<id>urn:sha1:0581ea5469a6440eac207b225145bb6b45f43756</id>
<content type='text'>
[ Upstream commit 78a61cd42a64f3587862b372a79e1d6aaf131fd7 ]

Bit 6 in the ANACAP field is used to indicate that the ANA group ID
doesn't change while the namespace is attached to the controller.
There is an optimisation in the code to only allocate space
for the ANA group header, as the namespace list won't change and
hence would not need to be refreshed.
However, this optimisation was never carried over to the actual
workflow, which always assumes that the buffer is large enough
to hold the ANA header _and_ the namespace list.
So drop this optimisation and always allocate enough space.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-rdma: fix timeout handler</title>
<updated>2019-03-05T16:59:41+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2019-01-08T08:53:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=161acb8d61dc1f31ebc29d91cb41bd3a6f39e668'/>
<id>urn:sha1:161acb8d61dc1f31ebc29d91cb41bd3a6f39e668</id>
<content type='text'>
[ Upstream commit 4c174e6366746ae8d49f9cc409f728eebb7a9ac9 ]

Currently, we have several problems with the timeout
handler:
1. If we timeout on the controller establishment flow, we will hang
because we don't execute the error recovery (and we shouldn't because
the create_ctrl flow needs to fail and cleanup on its own)
2. We might also hang if we get a disconnet on a queue while the
controller is already deleting. This racy flow can cause the controller
disable/shutdown admin command to hang.

We cannot complete a timed out request from the timeout handler without
mutual exclusion from the teardown flow (e.g. nvme_rdma_error_recovery_work).
So we serialize it in the timeout handler and teardown io and admin
queues to guarantee that no one races with us from completing the
request.

Reported-by: Jaesoo Lee &lt;jalee@purestorage.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: introduce NVME_QUIRK_IGNORE_DEV_SUBNQN</title>
<updated>2019-02-20T09:29:05+00:00</updated>
<author>
<name>James Dingwall</name>
<email>james@dingwall.me.uk</email>
</author>
<published>2019-01-08T17:20:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b9453f9bb66e864f8b7d7e112aea475bdd7a4e2b'/>
<id>urn:sha1:b9453f9bb66e864f8b7d7e112aea475bdd7a4e2b</id>
<content type='text'>
[ Upstream commit 6299358d198a0635da2dd3c4b3ec37789e811e44 ]

If a device provides an NQN it is expected to be globally unique.
Unfortunately some firmware revisions for Intel 760p/Pro 7600p devices did
not satisfy this requirement.  In these circumstances if a system has &gt;1
affected device then only one device is enabled.  If this quirk is enabled
then the device supplied subnqn is ignored and we fallback to generating
one as if the field was empty.  In this case we also suppress the version
check so we don't print a warning when the quirk is enabled.

Reviewed-by: Keith Busch &lt;keith.busch@intel.com&gt;
Signed-off-by: James Dingwall &lt;james@dingwall.me.uk&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: pad fake subsys NQN vid and ssvid with zeros</title>
<updated>2019-02-20T09:29:05+00:00</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2019-01-08T16:37:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cedcbfdde6d5e7336abc4592ac00846f78a9127a'/>
<id>urn:sha1:cedcbfdde6d5e7336abc4592ac00846f78a9127a</id>
<content type='text'>
[ Upstream commit 3da584f57133e51aeb84aaefae5e3d69531a1e4f ]

We need to preserve the leading zeros in the vid and ssvid when generating
a unique NQN. Truncating these may lead to naming collisions.

Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-multipath: zero out ANA log buffer</title>
<updated>2019-02-20T09:29:05+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2019-01-08T11:46:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=846cdc1a0305a77154fed0a86cf21b9f4e7a6c74'/>
<id>urn:sha1:846cdc1a0305a77154fed0a86cf21b9f4e7a6c74</id>
<content type='text'>
[ Upstream commit c7055fd15ff46d92eb0dd1c16a4fe010d58224c8 ]

When nvme_init_identify() fails the ANA log buffer is deallocated
but _not_ set to NULL. This can cause double free oops when this
controller is deleted without ever being reconnected.

Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-pci: fix out of bounds access in nvme_cqe_pending</title>
<updated>2019-02-20T09:29:04+00:00</updated>
<author>
<name>Hongbo Yao</name>
<email>yaohongbo@huawei.com</email>
</author>
<published>2019-01-07T02:22:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c4a6f6e7ef64e2cedfe6f4381c86b83f6687ec20'/>
<id>urn:sha1:c4a6f6e7ef64e2cedfe6f4381c86b83f6687ec20</id>
<content type='text'>
[ Upstream commit dcca1662727220d18fa351097ddff33f95f516c5 ]

There is an out of bounds array access in nvme_cqe_peding().

When enable irq_thread for nvme interrupt, there is racing between the
nvmeq-&gt;cq_head updating and reading.

nvmeq-&gt;cq_head is updated in nvme_update_cq_head(), if nvmeq-&gt;cq_head
equals nvmeq-&gt;q_depth and before its value set to zero, nvme_cqe_pending()
uses its value as an array index, the index will be out of bounds.

Signed-off-by: Hongbo Yao &lt;yaohongbo@huawei.com&gt;
[hch: slight coding style update]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-pci: use the same attributes when freeing host_mem_desc_bufs.</title>
<updated>2019-02-20T09:29:04+00:00</updated>
<author>
<name>Liviu Dudau</name>
<email>liviu@dudau.co.uk</email>
</author>
<published>2018-12-29T17:23:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e0b9c20716648530f1982314ffe0cb42d72b84fc'/>
<id>urn:sha1:e0b9c20716648530f1982314ffe0cb42d72b84fc</id>
<content type='text'>
[ Upstream commit cc667f6d5de023ee131e96bb88e5cddca23272bd ]

When using HMB the PCIe host driver allocates host_mem_desc_bufs using
dma_alloc_attrs() but frees them using dma_free_coherent(). Use the
correct dma_free_attrs() function to free the buffers.

Signed-off-by: Liviu Dudau &lt;liviu@dudau.co.uk&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
