linux.git/drivers/nvme, branch v4.14.49

nvme-pci: disable APST for Samsung NVMe SSD 960 EVO + ASUS PRIME Z370-A

2018-05-30T05:52:29+00:00

[ Upstream commit 467c77d4cbefaaf65e2f44fe102d543a52fcae5b ]

Yet another "incompatible" Samsung NVMe SSD 960 EVO and Asus motherboard
combination. 960 EVO device disappears from PCIe bus within few minutes
after boot-up when APST is in use and never gets back. Forcing
NVME_QUIRK_NO_APST is the only way to make this drive work with this
particular motherboard. NVME_QUIRK_NO_DEEPEST_PS doesn't work, upgrading
motherboard's BIOS didn't help either.
Since this is a desktop motherboard, the only drawback of not using APST
is increased device temperature.

Signed-off-by: Jarosław Janik 
Signed-off-by: Keith Busch 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme: don't send keep-alives to the discovery controller

2018-05-30T05:52:22+00:00

[ Upstream commit 74c6c71530847808d4e3be7b205719270efee80c ]

NVMe over Fabrics 1.0 Section 5.2 "Discovery Controller Properties and
Command Support" Figure 31 "Discovery Controller – Admin Commands"
explicitly listst all commands but "Get Log Page" and "Identify" as
reserved, but NetApp report the Linux host is sending Keep Alive
commands to the discovery controller, which is a violation of the
Spec.

We're already checking for discovery controllers when configuring the
keep alive timeout but when creating a discovery controller we're not
hard wiring the keep alive timeout to 0 and thus remain on
NVME_DEFAULT_KATO for the discovery controller.

This can be easily remproduced when issuing a direct connect to the
discovery susbsystem using:
'nvme connect [...] --nqn=nqn.2014-08.org.nvmexpress.discovery'

Signed-off-by: Johannes Thumshirn 
Fixes: 07bfcd09a288 ("nvme-fabrics: add a generic NVMe over Fabrics library")
Reported-by: Martin George 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Keith Busch 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme: pci: pass max vectors as num_possible_cpus() to pci_alloc_irq_vectors

2018-05-30T05:52:09+00:00

[ Upstream commit 16ccfff2897613007b5eda9e29d65303c6280026 ]

84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs")
has switched to do irq vectors spread among all possible CPUs, so
pass num_possible_cpus() as max vecotrs to be assigned.

For example, in a 8 cores system, 0~3 online, 4~8 offline/not present,
see 'lscpu':

        [ming@box]$lscpu
        Architecture:          x86_64
        CPU op-mode(s):        32-bit, 64-bit
        Byte Order:            Little Endian
        CPU(s):                4
        On-line CPU(s) list:   0-3
        Thread(s) per core:    1
        Core(s) per socket:    2
        Socket(s):             2
        NUMA node(s):          2
        ...
        NUMA node0 CPU(s):     0-3
        NUMA node1 CPU(s):
        ...

1) before this patch, follows the allocated vectors and their affinity:
	irq 47, cpu list 0,4
	irq 48, cpu list 1,6
	irq 49, cpu list 2,5
	irq 50, cpu list 3,7

2) after this patch, follows the allocated vectors and their affinity:
	irq 43, cpu list 0
	irq 44, cpu list 1
	irq 45, cpu list 2
	irq 46, cpu list 3
	irq 47, cpu list 4
	irq 48, cpu list 6
	irq 49, cpu list 5
	irq 50, cpu list 7

Cc: Keith Busch 
Cc: Sagi Grimberg 
Cc: Thomas Gleixner 
Cc: Christoph Hellwig 
Signed-off-by: Ming Lei 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme-pci: Fix EEH failure on ppc

2018-05-30T05:52:09+00:00

[ Upstream commit 651438bb0af5213f1f70d66e75bf11d08cb5537a ]

Triggering PPC EEH detection and handling requires a memory mapped read
failure. The NVMe driver removed the periodic health check MMIO, so
there's no early detection mechanism to trigger the recovery. Instead,
the detection now happens when the nvme driver handles an IO timeout
event. This takes the pci channel offline, so we do not want the driver
to proceed with escalating its own recovery efforts that may conflict
with the EEH handler.

This patch ensures the driver will observe the channel was set to offline
after a failed MMIO read and resets the IO timer so the EEH handler has
a chance to recover the device.

Signed-off-by: Wen Xiong 
[updated change log]
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvmet: fix PSDT field check in command format

2018-05-30T05:52:06+00:00

[ Upstream commit bffd2b61670feef18d2535e9b53364d270a1c991 ]

PSDT field section according to NVM_Express-1.3:
"This field specifies whether PRPs or SGLs are used for any data
transfer associated with the command. PRPs shall be used for all
Admin commands for NVMe over PCIe. SGLs shall be used for all Admin
and I/O commands for NVMe over Fabrics. This field shall be set to
01b for NVMe over Fabrics 1.0 implementations.

Suggested-by: Idan Burstein 
Signed-off-by: Max Gurtovoy 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme-pci: Fix nvme queue cleanup if IRQ setup fails

2018-05-30T05:52:04+00:00

[ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ]

This patch fixes nvme queue cleanup if requesting an IRQ handler for
the queue's vector fails. It does this by resetting the cq_vector to
the uninitialized value of -1 so it is ignored for a controller reset.

Signed-off-by: Jianchao Wang 
[changelog updates, removed misc whitespace changes]
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme: add quirk to force medium priority for SQ creation

2018-05-16T08:10:30+00:00

commit 9abd68ef454c824bfd18629033367b4382b5f390 upstream.

Some P3100 drives have a bug where they think WRRU (weighted round robin)
is always enabled, even though the host doesn't set it. Since they think
it's enabled, they also look at the submission queue creation priority. We
used to set that to MEDIUM by default, but that was removed in commit
81c1cd98351b. This causes various issues on that drive. Add a quirk to
still set MEDIUM priority for that controller.

Fixes: 81c1cd98351b ("nvme/pci: Don't set reserved SQ create flags")
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe 
Signed-off-by: Keith Busch 
Signed-off-by: Greg Kroah-Hartman

nvme_fcloop: fix abort race condition

2018-04-12T10:32:16+00:00

[ Upstream commit 278e096063f1914fccfc77a617be9fc8dbb31b0e ]

A test case revealed a race condition of an i/o completing on a thread
parallel to the delete_association generating the aborts for the
outstanding ios on the controller.  The i/o completion was freeing the
target fcloop context, thus the abort task referenced the just-freed
memory.

Correct by clearing the target/initiator cross pointers in the io
completion and abort tasks before calling the callbacks. On aborts
that detect already finished io's, ensure the complete context is
called.

Signed-off-by: James Smart 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme_fcloop: disassocate local port structs

2018-04-12T10:32:16+00:00

[ Upstream commit 6fda20283e55b9d288cd56822ce39fc8e64f2208 ]

The current fcloop driver gets its lport structure from the private
area co-allocated with the fc_localport. All is fine except the
teardown path, which wants to wait on the completion, which is marked
complete by the delete_localport callback performed after
unregister_localport.  The issue is, the nvme_fc transport frees the
localport structure immediately after delete_localport is called,
meaning the original routine is trying to wait on a complete that
was just freed.

Change such that a lport struct is allocated coincident with the
addition and registration of a localport. The private area of the
localport now contains just a backpointer to the real lport struct.
Now, the completion can be waited for, and after completing, the
new structure can be kfree'd.

Signed-off-by: James Smart 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme-rdma: don't suppress send completions

2018-03-09T06:41:26+00:00

commit b4b591c87f2b0f4ebaf3a68d4f13873b241aa584 upstream.

The entire completions suppress mechanism is currently broken because the
HCA might retry a send operation (due to dropped ack) after the nvme
transaction has completed.

In order to handle this, we signal all send completions and introduce a
separate done handler for async events as they will be handled differently
(as they don't include in-capsule data by definition).

Signed-off-by: Sagi Grimberg 
Reviewed-by: Max Gurtovoy 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman