linux-stable.git/drivers/nvme, branch v5.3.17

Revert "nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T"

2019-12-17T19:06:42+00:00

commit 655e7aee1f0398602627a485f7dca6c29cc96cae upstream.

Since e045fa29e893 ("PCI/MSI: Fix incorrect MSI-X masking on resume") is
merged, we can revert the previous quirk now.

This reverts commit 19ea025e1d28c629b369c3532a85b3df478cc5c6.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Fixes: 19ea025e1d28 ("nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T")
Link: https://lore.kernel.org/r/20191031093408.9322-1-jian-hong@endlessm.com
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Bjorn Helgaas 
Acked-by: Christoph Hellwig 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

nvme-multipath: fix crash in nvme_mpath_clear_ctrl_paths

2019-12-04T21:33:42+00:00

[ Upstream commit 763303a83a095a88c3a8a0d1abf97165db2e8bf5 ]

nvme_mpath_clear_ctrl_paths() iterates through
the ctrl->namespaces list while holding ctrl->scan_lock.
This does not seem to be the correct way of protecting
from concurrent list modification.

Specifically, nvme_scan_work() sorts ctrl->namespaces
AFTER unlocking scan_lock.

This may result in the following (rare) crash in ctrl disconnect
during scan_work:

    BUG: kernel NULL pointer dereference, address: 0000000000000050
    Oops: 0000 [#1] SMP PTI
    CPU: 0 PID: 3995 Comm: nvme 5.3.5-050305-generic
    RIP: 0010:nvme_mpath_clear_current_path+0xe/0x90 [nvme_core]
    ...
    Call Trace:
     nvme_mpath_clear_ctrl_paths+0x3c/0x70 [nvme_core]
     nvme_remove_namespaces+0x35/0xe0 [nvme_core]
     nvme_do_delete_ctrl+0x47/0x90 [nvme_core]
     nvme_sysfs_delete+0x49/0x60 [nvme_core]
     dev_attr_store+0x17/0x30
     sysfs_kf_write+0x3e/0x50
     kernfs_fop_write+0x11e/0x1a0
     __vfs_write+0x1b/0x40
     vfs_write+0xb9/0x1a0
     ksys_write+0x67/0xe0
     __x64_sys_write+0x1a/0x20
     do_syscall_64+0x5a/0x130
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x7f8d02bfb154

Fix:
After taking scan_lock in nvme_mpath_clear_ctrl_paths()
down_read(&ctrl->namespaces_rwsem) as well to make list traversal safe.
This will not cause deadlocks because taking scan_lock never happens
while holding the namespaces_rwsem.
Moreover, scan work downs namespaces_rwsem in the same order.

Alternative: sort ctrl->namespaces in nvme_scan_work()
while still holding the scan_lock.
This would leave nvme_mpath_clear_ctrl_paths() without correct protection
against ctrl->namespaces modification by anyone other than scan_work.

Reviewed-by: Sagi Grimberg 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Anton Eidelman 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvme-rdma: fix a segmentation fault during module unload

2019-12-04T21:33:41+00:00

[ Upstream commit 9ad9e8d6ca29c1446d81c6518ae634a2141dfd22 ]

In case there are controllers that are not associated with any RDMA
device (e.g. during unsuccessful reconnection) and the user will unload
the module, these controllers will not be freed and will access already
freed memory. The same logic appears in other fabric drivers as well.

Fixes: 87fd125344d6 ("nvme-rdma: remove redundant reference between ib_device and tagset")
Reviewed-by: Sagi Grimberg 
Signed-off-by: Max Gurtovoy 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvme-multipath: fix possible io hang after ctrl reconnect

2019-11-12T18:28:07+00:00

[ Upstream commit af8fd0424713a2adb812d10d55e86718152cf656 ]

The following scenario results in an IO hang:
1) ctrl completes a request with NVME_SC_ANA_TRANSITION.
   NVME_NS_ANA_PENDING bit in ns->flags is set and ana_work is triggered.
2) ana_work: nvme_read_ana_log() tries to get the ANA log page from the ctrl.
   This fails because ctrl disconnects.
   Therefore nvme_update_ns_ana_state() is not called
   and NVME_NS_ANA_PENDING bit in ns->flags is not cleared.
3) ctrl reconnects: nvme_mpath_init(ctrl,...) calls
   nvme_read_ana_log(ctrl, groups_only=true).
   However, nvme_update_ana_state() does not update namespaces
   because nr_nsids = 0 (due to groups_only mode).
4) scan_work calls nvme_validate_ns() finds the ns and re-validates OK.

Result:
The ctrl is now live but NVME_NS_ANA_PENDING bit in ns->flags is still set.
Consequently ctrl will never be considered a viable path by __nvme_find_path().
IO will hang if ctrl is the only or the last path to the namespace.

More generally, while ctrl is reconnecting, its ANA state may change.
And because nvme_mpath_init() requests ANA log in groups_only mode,
these changes are not propagated to the existing ctrl namespaces.
This may result in a mal-function or an IO hang.

Solution:
nvme_mpath_init() will nvme_read_ana_log() with groups_only set to false.
This will not harm the new ctrl case (no namespaces present),
and will make sure the ANA state of namespaces gets updated after reconnect.

Note: Another option would be for nvme_mpath_init() to invoke
nvme_parse_ana_log(..., nvme_set_ns_ana_state) for each existing namespace.

Reviewed-by: Sagi Grimberg 
Signed-off-by: Anton Eidelman 
Signed-off-by: Keith Busch 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

Revert "nvme: allow 64-bit results in passthru commands"

2019-11-06T12:09:35+00:00

This reverts commit 76d609da9ed1cc0dc780e2b539d7b827ce28f182.

The patch adds new functionality and shouldn't have been backported.

Signed-off-by: Sasha Levin

nvme-pci: Set the prp2 correctly when using more than 4k page

2019-10-29T08:21:51+00:00

commit a4f40484e7f1dff56bb9f286cc59ffa36e0259eb upstream.

In the current code, the nvme is using a fixed 4k PRP entry size,
but if the kernel use a page size which is more than 4k, we should
consider the situation that the bv_offset may be larger than the
dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
cause the command can't be executed correctly.

Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: Kevin Hao 
Signed-off-by: Keith Busch 
Signed-off-by: Greg Kroah-Hartman

nvme-rdma: fix possible use-after-free in connect timeout

2019-10-29T08:21:32+00:00

[ Upstream commit 67b483dd03c4cd9e90e4c3943132dce514ea4e88 ]

If the connect times out, we may have already destroyed the
queue in the timeout handler, so test if the queue is still
allocated in the connect error handler.

Reported-by: Yi Zhang 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin

nvme: allow 64-bit results in passthru commands

2019-10-29T08:21:31+00:00

[ Upstream commit 65e68edce0db433aa0c2b26d7dc14fbbbeb89fbb ]

It is not possible to get 64-bit results from the passthru commands,
what prevents from getting for the Capabilities (CAP) property value.

As a result, it is not possible to implement IOL's NVMe Conformance
test 4.3 Case 1 for Fabrics targets [1] (page 123).

This issue has been already discussed [2], but without a solution.

This patch solves the problem by adding new ioctls with a new
passthru structure, including 64-bit results. The older ioctls stay
unchanged.

[1] https://www.iol.unh.edu/sites/default/files/testsuites/nvme/UNH-IOL_NVMe_Conformance_Test_Suite_v11.0.pdf
[2] http://lists.infradead.org/pipermail/linux-nvme/2018-June/018791.html

Signed-off-by: Marta Rybczynska 
Reviewed-by: Keith Busch 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin

nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T

2019-10-29T08:21:30+00:00

[ Upstream commit 19ea025e1d28c629b369c3532a85b3df478cc5c6 ]

Kingston NVME SSD with firmware version E8FK11.T has no interrupt after
resume with actions related to suspend to idle. This patch applied
NVME_QUIRK_SIMPLE_SUSPEND quirk to fix this issue.

Fixes: d916b1be94b6 ("nvme-pci: use host managed power state for suspend")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin

Added QUIRKs for ADATA XPG SX8200 Pro 512GB

2019-10-29T08:21:30+00:00

[ Upstream commit f03e42c6af60f778a6d1ccfb857db9b2ec835279 ]

Booting with default_ps_max_latency_us >6000 makes the device fail.
Also SUBNQN is NULL and gives a warning on each boot/resume.
 $ nvme id-ctrl /dev/nvme0 | grep ^subnqn
   subnqn    : (null)

I use this device with an Acer Nitro 5 (AN515-43-R8BF) Laptop.
To be sure is not a Laptop issue only, I tested the device on
my server board  with the same results.
( with 2x,4x link on the board and 4x link on a PCI-E card ).

Signed-off-by: Gabriel Craciunescu 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin