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

nvme: add command id quirk for apple controllers

2021-10-06T13:55:59+00:00

commit a2941f6aa71a72be2c82c0a168523a492d093530 upstream.

Some apple controllers use the command id as an index to implementation
specific data structures and will fail if the value is out of bounds.
The nvme driver's recently introduced command sequence number breaks
this controller.

Provide a quirk so these spec incompliant controllers can function as
before. The driver will not have the ability to detect bad completions
when this quirk is used, but we weren't previously checking this anyway.

The quirk bit was selected so that it can readily apply to stable.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=214509
Cc: Sven Peter 
Reported-by: Orlando Chamberlain 
Reported-by: Aditya Garg 
Signed-off-by: Keith Busch 
Reviewed-by: Christoph Hellwig 
Tested-by: Sven Peter 
Link: https://lore.kernel.org/r/20210927154306.387437-1-kbusch@kernel.org
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

nvme-rdma: destroy cm id before destroy qp to avoid use after free

2021-09-30T08:11:06+00:00

[ Upstream commit 9817d763dbe15327b9b3ff4404fa6f27f927e744 ]

We should always destroy cm_id before destroy qp to avoid to get cma
event after qp was destroyed, which may lead to use after free.
In RDMA connection establishment error flow, don't destroy qp in cm
event handler.Just report cm_error to upper level, qp will be destroy
in nvme_rdma_alloc_queue() after destroy cm id.

Signed-off-by: Ruozhu Li 
Reviewed-by: Max Gurtovoy 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-multipath: fix ANA state updates when a namespace is not present

2021-09-30T08:11:06+00:00

[ Upstream commit 79f528afa93918519574773ea49a444c104bc1bd ]

nvme_update_ana_state() has a deficiency that results in a failure to
properly update the ana state for a namespace in the following case:

  NSIDs in ctrl->namespaces:	1, 3,    4
  NSIDs in desc->nsids:		1, 2, 3, 4

Loop iteration 0:
    ns index = 0, n = 0, ns->head->ns_id = 1, nsid = 1, MATCH.
Loop iteration 1:
    ns index = 1, n = 1, ns->head->ns_id = 3, nsid = 2, NO MATCH.
Loop iteration 2:
    ns index = 2, n = 2, ns->head->ns_id = 4, nsid = 4, MATCH.

Where the update to the ANA state of NSID 3 is missed.  To fix this
increment n and retry the update with the same ns when ns->head->ns_id is
higher than nsid,

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

nvme: keep ctrl->namespaces ordered

2021-09-30T08:11:04+00:00

[ Upstream commit 298ba0e3d4af539cc37f982d4c011a0f07fca48c ]

Various places in the nvme code that rely on ctrl->namespace to be
ordered.  Ensure that the namespae is inserted into the list at the
right position from the start instead of sorting it after the fact.

Fixes: 540c801c65eb ("NVMe: Implement namespace list scanning")
Reported-by: Anton Eidelman 
Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Chaitanya Kulkarni 
Reviewed-by: Damien Le Moal 
Signed-off-by: Sasha Levin

treewide: Change list_sort to use const pointers

2021-09-30T08:11:04+00:00

[ Upstream commit 4f0f586bf0c898233d8f316f471a21db2abd522d ]

list_sort() internally casts the comparison function passed to it
to a different type with constant struct list_head pointers, and
uses this pointer to call the functions, which trips indirect call
Control-Flow Integrity (CFI) checking.

Instead of removing the consts, this change defines the
list_cmp_func_t type and changes the comparison function types of
all list_sort() callers to use const pointers, thus avoiding type
mismatches.

Suggested-by: Nick Desaulniers 
Signed-off-by: Sami Tolvanen 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Kees Cook 
Tested-by: Nick Desaulniers 
Tested-by: Nathan Chancellor 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20210408182843.1754385-10-samitolvanen@google.com
Signed-off-by: Sasha Levin

nvme-tcp: fix incorrect h2cdata pdu offset accounting

2021-09-30T08:11:04+00:00

[ Upstream commit e371af033c560b9dd1e861f8f0b503142bf0a06c ]

When the controller sends us multiple r2t PDUs in a single
request we need to account for it correctly as our send/recv
context run concurrently (i.e. we get a new r2t with r2t_offset
before we updated our iterator and req->data_sent marker). This
can cause wrong offsets to be sent to the controller.

To fix that, we will first know that this may happen only in
the send sequence of the last page, hence we will take
the r2t_offset to the h2c PDU data_offset, and in
nvme_tcp_try_send_data loop, we make sure to increment
the request markers also when we completed a PDU but
we are expecting more r2t PDUs as we still did not send
the entire data of the request.

Fixes: 825619b09ad3 ("nvme-tcp: fix possible use-after-completion")
Reported-by: Nowak, Lukasz 
Tested-by: Nowak, Lukasz 
Signed-off-by: Sagi Grimberg 
Reviewed-by: Keith Busch 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-tcp: fix io_work priority inversion

2021-09-22T10:27:57+00:00

commit 70f437fb4395ad4d1d16fab9a1ad9fbc9fc0579b upstream.

Dispatching requests inline with the .queue_rq() call may block while
holding the send_mutex. If the tcp io_work also happens to schedule, it
may see the req_list is non-empty, leaving "pending" true and remaining
in TASK_RUNNING. Since io_work is of higher scheduling priority, the
.queue_rq task may not get a chance to run, blocking forward progress
and leading to io timeouts.

Instead of checking for pending requests within io_work, let the queueing
restart io_work outside the send_mutex lock if there is more work to be
done.

Fixes: a0fdd1418007f ("nvme-tcp: rerun io_work if req_list is not empty")
Reported-by: Samuel Jones 
Signed-off-by: Keith Busch 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman

nvme: code command_id with a genctr for use-after-free validation

2021-09-18T11:40:29+00:00

[ Upstream commit e7006de6c23803799be000a5dcce4d916a36541a ]

We cannot detect a (perhaps buggy) controller that is sending us
a completion for a request that was already completed (for example
sending a completion twice), this phenomenon was seen in the wild
a few times.

So to protect against this, we use the upper 4 msbits of the nvme sqe
command_id to use as a 4-bit generation counter and verify it matches
the existing request generation that is incrementing on every execution.

The 16-bit command_id structure now is constructed by:
| xxxx | xxxxxxxxxxxx |
  gen    request tag

This means that we are giving up some possible queue depth as 12 bits
allow for a maximum queue depth of 4095 instead of 65536, however we
never create such long queues anyways so no real harm done.

Suggested-by: Keith Busch 
Signed-off-by: Sagi Grimberg 
Acked-by: Keith Busch 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Daniel Wagner 
Tested-by: Daniel Wagner 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-tcp: don't check blk_mq_tag_to_rq when receiving pdu data

2021-09-18T11:40:28+00:00

[ Upstream commit 3b01a9d0caa8276d9ce314e09610f7fb70f49a00 ]

We already validate it when receiving the c2hdata pdu header
and this is not changing so this is a redundant check.

Reviewed-by: Hannes Reinecke 
Signed-off-by: Sagi Grimberg 
Reviewed-by: Daniel Wagner 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvmet: pass back cntlid on successful completion

2021-09-15T07:50:25+00:00

[ Upstream commit e804d5abe2d74cfe23f5f83be580d1cdc9307111 ]

According to the NVMe specification, the response dword 0 value of the
Connect command is based on status code: return cntlid for successful
compeltion return IPO and IATTR for connect invalid parameters.  Fix
a missing error information for a zero sized queue, and return the
cntlid also for I/O queue Connect commands.

Signed-off-by: Amit Engel 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin