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

nvme: Fix u32 overflow in the number of namespace list calculation

2019-06-25T03:35:59+00:00

[ Upstream commit c8e8c77b3bdbade6e26e8e76595f141ede12b692 ]

The Number of Namespaces (nn) field in the identify controller data structure is
defined as u32 and the maximum allowed value in NVMe specification is
0xFFFFFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP()
operation used in nvme_scan_ns_list() by casting the nn to u64.

Signed-off-by: Jaesoo Lee 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin

nvmet: fix data_len to 0 for bdev-backed write_zeroes

2019-06-25T03:35:58+00:00

[ Upstream commit 3562f5d9f21e7779ae442a45197fed6cb247fd22 ]

The WRITE ZEROES command has no data transfer so that we need to
initialize the struct (nvmet_req *req)->data_len to 0x0.  While
(nvmet_req *req)->transfer_len is initialized in nvmet_req_init(),
data_len will be initialized by nowhere which might cause the failure
with status code NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR randomly.  It's
because nvmet_req_execute() checks like:

	if (unlikely(req->data_len != req->transfer_len)) {
		req->error_loc = offsetof(struct nvme_common_command, dptr);
		nvmet_req_complete(req, NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR);
	} else
		req->execute(req);

This patch fixes req->data_len not to be a randomly assigned by
initializing it to 0x0 when preparing the command in
nvmet_bdev_parse_io_cmd().

nvmet_file_parse_io_cmd() which is for file-backed I/O has already
initialized the data_len field to 0x0, though.

Cc: Christoph Hellwig 
Cc: Sagi Grimberg 
Cc: Chaitanya Kulkarni 
Signed-off-by: Minwoo Im 
Reviewed-by: Chaitanya Kulkarni 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin

nvme: fix memory leak for power latency tolerance

2019-06-19T06:18:03+00:00

[ Upstream commit 510a405d945bc985abc513fafe45890cac34fafa ]

Unconditionally hide device pm latency tolerance when uninitializing
the controller to ensure all qos resources are released so that we're
not leaking this memory. This is safe to call if none were allocated in
the first place, or were previously freed.

Fixes: c5552fde102fc("nvme: Enable autonomous power state transitions")
Suggested-by: Keith Busch 
Tested-by: David Milburn 
Signed-off-by: Yufen Yu 
[changelog]
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvme: release namespace SRCU protection before performing controller ioctls

2019-06-19T06:18:03+00:00

[ Upstream commit 5fb4aac756acacf260b9ebd88747251effa3a2f2 ]

Holding the SRCU critical section protecting the namespace list can
cause deadlocks when using the per-namespace admin passthrough ioctl to
delete as namespace.  Release it earlier when performing per-controller
ioctls to avoid that.

Reported-by: Kenneth Heitke 
Reviewed-by: Chaitanya Kulkarni 
Reviewed-by: Keith Busch 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme: merge nvme_ns_ioctl into nvme_ioctl

2019-06-19T06:18:03+00:00

[ Upstream commit 90ec611adcf20b96d0c2b7166497d53e4301a57f ]

Merge the two functions to make future changes a little easier.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Chaitanya Kulkarni 
Signed-off-by: Sasha Levin

nvme: remove the ifdef around nvme_nvm_ioctl

2019-06-19T06:18:02+00:00

[ Upstream commit 3f98bcc58cd5f1e4668db289dcab771874cc0920 ]

We already have a proper stub if lightnvm is not enabled, so don't bother
with the ifdef.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Chaitanya Kulkarni 
Signed-off-by: Sasha Levin

nvme: fix srcu locking on error return in nvme_get_ns_from_disk

2019-06-19T06:18:02+00:00

[ Upstream commit 100c815cbd56480b3e31518475b04719c363614a ]

If we can't get a namespace don't leak the SRCU lock.  nvme_ioctl was
working around this, but nvme_pr_command wasn't handling this properly.
Just do what callers would usually expect.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Chaitanya Kulkarni 
Signed-off-by: Sasha Levin

nvme-pci: shutdown on timeout during deletion

2019-06-15T09:54:06+00:00

[ Upstream commit 9dc1a38ef1925d23c2933c5867df816386d92ff8 ]

We do not restart a controller in a deleting state for timeout errors.
When in this state, unblock potential request dispatchers with failed
completions by shutting down the controller on timeout detection.

Reported-by: Yufen Yu 
Signed-off-by: Keith Busch 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-pci: unquiesce admin queue on shutdown

2019-06-15T09:54:06+00:00

[ Upstream commit c8e9e9b7646ebe1c5066ddc420d7630876277eb4 ]

Just like IO queues, the admin queue also will not be restarted after a
controller shutdown. Unquiesce this queue so that we do not block
request dispatch on a permanently disabled controller.

Reported-by: Yufen Yu 
Signed-off-by: Keith Busch 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-rdma: fix a NULL deref when an admin connect times out

2019-05-31T13:46:15+00:00

[ Upstream commit 1007709d7d06fab09bf2d007657575958676282b ]

If we timeout the admin startup sequence we might not yet have
an I/O tagset allocated which causes the teardown sequence to crash.
Make nvme_tcp_teardown_io_queues safe by not iterating inflight tags
if the tagset wasn't allocated.

Fixes: 4c174e636674 ("nvme-rdma: fix timeout handler")
Signed-off-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin