linux.git/drivers/nvme, branch v5.1-rc2

Merge tag 'for-5.1/block-post-20190315' of git://git.kernel.dk/linux-block

2019-03-16T19:36:39+00:00

Pull more block layer changes from Jens Axboe:
 "This is a collection of both stragglers, and fixes that came in after
  I finalized the initial pull. This contains:

   - An MD pull request from Song, with a few minor fixes

   - Set of NVMe patches via Christoph

   - Pull request from Konrad, with a few fixes for xen/blkback

   - pblk fix IO calculation fix (Javier)

   - Segment calculation fix for pass-through (Ming)

   - Fallthrough annotation for blkcg (Mathieu)"

* tag 'for-5.1/block-post-20190315' of git://git.kernel.dk/linux-block: (25 commits)
  blkcg: annotate implicit fall through
  nvme-tcp: support C2HData with SUCCESS flag
  nvmet: ignore EOPNOTSUPP for discard
  nvme: add proper write zeroes setup for the multipath device
  nvme: add proper discard setup for the multipath device
  nvme: remove nvme_ns_config_oncs
  nvme: disable Write Zeroes for qemu controllers
  nvmet-fc: bring Disconnect into compliance with FC-NVME spec
  nvmet-fc: fix issues with targetport assoc_list list walking
  nvme-fc: reject reconnect if io queue count is reduced to zero
  nvme-fc: fix numa_node when dev is null
  nvme-fc: use nr_phys_segments to determine existence of sgl
  nvme-loop: init nvmet_ctrl fatal_err_work when allocate
  nvme: update comment to make the code easier to read
  nvme: put ns_head ref if namespace fails allocation
  nvme-trace: fix cdw10 buffer overrun
  nvme: don't warn on block content change effects
  nvme: add get-feature to admin cmds tracer
  md: Fix failed allocation of md_register_thread
  It's wrong to add len to sector_nr in raid10 reshape twice
  ...

nvme-tcp: support C2HData with SUCCESS flag

2019-03-13T18:57:34+00:00

A C2HData PDU with the SUCCESS flag set indicates that the I/O was
completed by the controller successfully and means that a subsequent
completion response capsule PDU will be ommitted.

If we see this flag, fisrt we check that LAST_PDU flag is set as well,
and then we complete the request when the data transfer (and data digest
verification if its on) is done.

While we're at it, reuse a bit of code with nvme_fail_request.

Reported-by: Steve Blightman 
Suggested-by: Oliver Smith-Denny 
Signed-off-by: Sagi Grimberg 
Reviewed-by: Oliver Smith-Denny 
Tested-by: Oliver Smith-Denny 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

nvmet: ignore EOPNOTSUPP for discard

2019-03-13T18:57:34+00:00

NVMe DSM is a pure hint, so if the underlying device / file system
does not support discard-like operations we should not fail the
operation but rather return success.

Fixes: 3b031d15995f ("nvmet: add error log support for bdev backend")
Signed-off-by: Christoph Hellwig 
Reviewed by: Chaitanya Kulkarni 
Tested-by: Sagi Grimberg 
Signed-off-by: Jens Axboe

nvme: add proper write zeroes setup for the multipath device

2019-03-13T18:57:34+00:00

Add a gendisk argument to nvme_config_write_zeroes so that the call to
nvme_update_disk_info for the multipath device node updates the
proper request_queue.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Max Gurtovoy 
Tested-by: Sagi Grimberg 
Signed-off-by: Jens Axboe

nvme: add proper discard setup for the multipath device

2019-03-13T18:57:34+00:00

Add a gendisk argument to nvme_config_discard so that the call to
nvme_update_disk_info for the multipath device node updates the
proper request_queue.

Signed-off-by: Christoph Hellwig 
Reported-by: Sagi Grimberg 
Reviewed-by: Keith Busch 
Reviewed-by: Max Gurtovoy 
Tested-by: Sagi Grimberg 
Signed-off-by: Jens Axboe

nvme: remove nvme_ns_config_oncs

2019-03-13T18:57:34+00:00

Just opencode the two function calls in the caller.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Max Gurtovoy 
Reviewed-by: Chaitanya Kulkarni 
Tested-by: Sagi Grimberg 
Signed-off-by: Jens Axboe

nvme: disable Write Zeroes for qemu controllers

2019-03-13T18:57:34+00:00

Qemu started out with a broken implementation of Write Zeroes written
by yours truly.  Disable Write Zeroes on qemu for now, eventually
we need to go back and make all the qemu quirks version specific,
but that is left for another time.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Tested-by: Ming Lei 
Signed-off-by: Jens Axboe

nvmet-fc: bring Disconnect into compliance with FC-NVME spec

2019-03-13T18:57:34+00:00

The FC-NVME spec, when finally approved, modified the disconnect LS
such that the only scope available is the association.

Rework the Disconnect LS processing to be in accordance with the
change.

Signed-off-by: Nigel Kirkland 
Signed-off-by: James Smart 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

nvmet-fc: fix issues with targetport assoc_list list walking

2019-03-13T18:57:30+00:00

There are two changes:

1) The logic in the __nvmet_fc_free_assoc() routine is bad. It uses
"safe" routines assuming pointers will come back valid.  However, the
intervening next structure being linked can be removed from the list and
the resulting safe pointers are bad, resulting in NULL ptrs being hit.

Correct by scheduling a work element to perform the association delete,
which can be done while under lock.

2) Prior patch that added the work element scheduling left a possible
reference on the object if the work element couldn't be scheduled.

Correct by doing the put on a failing schedule_work() call.

Signed-off-by: Nigel Kirkland 
Signed-off-by: James Smart 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

nvme-fc: reject reconnect if io queue count is reduced to zero

2019-03-13T18:05:40+00:00

If:

 - A successful connect has occurred with an io queue count greater than
   zero and namespaces detected and running.
 - An error or something occurs which causes a termination of the prior
   association and then starts a reconnect,
 - The reconnect then creates a new controller, but for whatever reason,
   nvme_set_queue_count() results in io queue count set to zero.  This
   will skip io queue and tag set changes.
 - But... the controller will transition to live, calling
   nvme_start_ctrl, which calls nvme_start_queues(), which then releases
   I/Os into the transport which then sends them to the driver.

As there are no queues, things eventually hit the driver looking for a
handle, which was cleared when the original controller was reset, and it
can't proceed. Worst case, things progress, but everything fails.

In the failing scenario, the nvme_set_features(NVME_FEAT_NUM_QUEUES)
command actually failed with a NVME_SC_INTERNAL error.  For some reason,
although nvme_set_queue_count() saw the error and set io queue count to
zero, it doesn't return a failure status to the transport, which allows
the transport to continue using the controller.

Fix the problem by simply rejecting the new association if at least 1
I/O queue can't be created. The association reject will fail the
reconnect attempt and fall into the reconnect retry policy.

Signed-off-by: James Smart 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe