linux-stable.git/drivers/nvme, branch linux-4.15.y

nvme: Skip checking heads without namespaces

2018-04-19T06:55:10+00:00

commit 2079699c10c8c60a9572540c2f77d045abf036eb upstream.

If a task is holding a reference to a namespace on a removed controller,
the head will not be released. If the same controller is added again
later, its namespaces may not be successfully added. Instead, the user
will see kernel message "Duplicate IDs for nsid ".

This patch fixes that by skipping heads that don't have namespaces when
considering if a new namespace is safe to add.

Reported-by: Alex Gagniuc 
Cc: stable@vger.kernel.org
Signed-off-by: Keith Busch 
Reviewed-by: Max Gurtovoy 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

nvme_fcloop: fix abort race condition

2018-04-12T10:31:08+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:31:08+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-fabrics: don't check for non-NULL module in nvmf_register_transport

2018-04-12T10:31:07+00:00

commit 5a1e59533380a3fd04593e4ab2d4633ebf7745c1 upstream.

THIS_MODULE evaluates to NULL when used from code built into the kernel,
thus breaking built-in transport modules.  Remove the bogus check.

Fixes: 0de5cd36 ("nvme-fabrics: protect against module unload during create_ctrl")
Signed-off-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Keith Busch 
Signed-off-by: Greg Kroah-Hartman

nvme-fabrics: protect against module unload during create_ctrl

2018-04-12T10:31:07+00:00

[ Upstream commit 0de5cd367c6aa2a31a1c931628f778f79f8ef22e ]

NVMe transport driver module unload may (and usually does) trigger
iteration over the active controllers and delete them all (sometimes
under a mutex).  However, a controller can be created concurrently with
module unload which can lead to leakage of resources (most important char
device node leakage) in case the controller creation occured after the
unload delete and drain sequence.  To protect against this, we take a
module reference to guarantee that the nvme transport driver is not
unloaded while creating a controller.

Signed-off-by: Roy Shterman 
Signed-off-by: Sagi Grimberg 
Reviewed-by: Max Gurtovoy 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nvme: fix subsystem multiple controllers support check

2018-03-21T11:05:45+00:00

commit b837b28394fb76993c28bb242db7061ee0417da6 upstream.

There is a problem when another module (e.g. nvmet) takes a reference on
the nvme block device and the physical nvme drive is removed.  In that
case nvme_free_ctrl() will not be called and the controller state will be
"deleting" or "dead" unless nvmet module releases the block device.
Later on, the same nvme drive probes back and nvme_init_subsystem() will
be called and fail due to duplicate subnqn (if the nvme device doesn't
support subsystem with multiple controllers). This will cause a probe
failure.  This commit changes the check of multiple controllers support
at nvme_init_subsystem() by not counting all the controllers at "dead" or
"deleting" state (this is safe because controllers at this state will
never be active again).

Fixes: ab9e00cc72fa ("nvme: track subsystems")
Reviewed-by: Max Gurtovoy 
Signed-off-by: Israel Rukshin 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Keith Busch 
Signed-off-by: Greg Kroah-Hartman

Revert "nvme: create 'slaves' and 'holders' entries for hidden controllers"

2018-03-15T09:56:50+00:00

commit 8a30ecc6e0ecbb9ae95daf499b2680b885ed0349 upstream.

This reverts commit e9a48034d7d1318ece7d4a235838a86c94db9d68.

The slaves and holders link for the hidden gendisks confuse lsblk so that
it errors out on, or doesn't report the nvme multipath devices.  Given
that we don't need holder relationships for something that can't even be
directly accessed we should just stop creating those links.

Signed-off-by: Christoph Hellwig 
Reported-by: Potnuri Bharat Teja 
Cc: stable@vger.kernel.org
Signed-off-by: Keith Busch 
Signed-off-by: Greg Kroah-Hartman

nvme-pci: take sglist coalescing in dma_map_sg into account

2018-01-17T21:05:35+00:00

Some iommu implementations can merge physically and/or virtually
contiguous segments inside sg_map_dma.  The NVMe SGL support does not take
this into account and will warn because of falling off a loop.  Pass the
number of mapped segments to nvme_pci_setup_sgls so that the SGL setup
can take the number of mapped segments into account.

Reported-by: Fangjian (Turing) 
Fixes: a7a7cbe3 ("nvme-pci: add SGL support")
Signed-off-by: Christoph Hellwig 
Reviewed-by: Keith Busch 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Jens Axboe

nvme-pci: check segement valid for SGL use

2018-01-17T21:05:33+00:00

The driver needs to verify there is a payload with a command before
seeing if it should use SGLs to map it.

Fixes: 955b1b5a00ba ("nvme-pci: move use_sgl initialization to nvme_init_iod()")
Reported-by: Paul Menzel 
Reviewed-by: Paul Menzel 
Signed-off-by: Keith Busch 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

nvme-fabrics: initialize default host->id in nvmf_host_default()

2018-01-08T09:52:03+00:00

The field was uninitialized before use.

Signed-off-by: Ewan D. Milne 
Signed-off-by: Christoph Hellwig