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

nvme: avoid race in shutdown namespace removal

2021-09-22T10:39:24+00:00

[ Upstream commit 9edceaf43050f5ba1dd7d0011bcf68a736a17743 ]

When we remove the siblings entry, we update ns->head->list, hence we
can't separate the removal and test for being empty. They have to be
in the same critical section to avoid a race.

To avoid breaking the refcounting imbalance again, add a list empty
check to nvme_find_ns_head.

Fixes: 5396fdac56d8 ("nvme: fix refcounting imbalance when all paths are down")
Signed-off-by: Daniel Wagner 
Reviewed-by: Hannes Reinecke 
Tested-by: Hannes Reinecke 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-tcp: fix io_work priority inversion

2021-09-22T10:39:20+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:43:51+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:43:51+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-15T08:02:04+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

nvme-rdma: don't update queue count when failing to set io queues

2021-09-15T08:02:04+00:00

[ Upstream commit 85032874f80ba17bf187de1d14d9603bf3f582b8 ]

We update ctrl->queue_count and schedule another reconnect when io queue
count is zero.But we will never try to create any io queue in next reco-
nnection, because ctrl->queue_count already set to zero.We will end up
having an admin-only session in Live state, which is exactly what we try
to avoid in the original patch.
Update ctrl->queue_count after queue_count zero checking to fix it.

Signed-off-by: Ruozhu Li 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

nvme-tcp: don't update queue count when failing to set io queues

2021-09-15T08:02:03+00:00

[ Upstream commit 664227fde63844d69e9ec9e90a8a7801e6ff072d ]

We update ctrl->queue_count and schedule another reconnect when io queue
count is zero.But we will never try to create any io queue in next reco-
nnection, because ctrl->queue_count already set to zero.We will end up
having an admin-only session in Live state, which is exactly what we try
to avoid in the original patch.
Update ctrl->queue_count after queue_count zero checking to fix it.

Signed-off-by: Ruozhu Li 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

Merge tag 'block-5.14-2021-07-24' of git://git.kernel.dk/linux-block

2021-07-24T19:57:06+00:00

Pull block fixes from Jens Axboe:

 - NVMe pull request (Christoph):
    - tracing fix (Keith Busch)
    - fix multipath head refcounting (Hannes Reinecke)
    - Write Zeroes vs PI fix (me)
    - drop a bogus WARN_ON (Zhihao Cheng)

 - Increase max blk-cgroup policy size, now that mq-deadline
   uses it too (Oleksandr)

* tag 'block-5.14-2021-07-24' of git://git.kernel.dk/linux-block:
  nvme: set the PRACT bit when using Write Zeroes with T10 PI
  nvme: fix nvme_setup_command metadata trace event
  nvme: fix refcounting imbalance when all paths are down
  nvme-pci: don't WARN_ON in nvme_reset_work if ctrl.state is not RESETTING
  block: increase BLKCG_MAX_POLS

nvme: set the PRACT bit when using Write Zeroes with T10 PI

2021-07-21T15:24:10+00:00

When using Write Zeroes on a namespace that has protection
information enabled they behavior without the PRACT bit
counter-intuitive and will generally lead to validation failures
when reading the written blocks.  Fix this by always setting the
PRACT bit that generates matching PI data on the fly.

Fixes: 6e02318eaea5 ("nvme: add support for the Write Zeroes command")
Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Martin K. Petersen

nvme: fix nvme_setup_command metadata trace event

2021-07-21T07:55:44+00:00

The metadata address is set after the trace event, so the trace is not
capturing anything useful. Rather than logging the memory address, it's
useful to know if the command carries a metadata payload, so change the
trace event to log that true/false state instead.

Signed-off-by: Keith Busch 
Signed-off-by: Christoph Hellwig