linux-stable.git/drivers/lightnvm/core.c, branch v5.3

lightnvm: fix uninitialized pointer in nvm_remove_tgt()

2019-06-21T09:14:30+00:00

With gcc 4.1:

    drivers/lightnvm/core.c: In function ‘nvm_remove_tgt’:
    drivers/lightnvm/core.c:510: warning: ‘t’ is used uninitialized in this function

Indeed, if no NVM devices have been registered, t will be an
uninitialized pointer, and may be dereferenced later.  A call to
nvm_remove_tgt() can be triggered from userspace by issuing the
NVM_DEV_REMOVE ioctl on the lightnvm control device.

Fix this by preinitializing t to NULL.

Fixes: 843f2edbdde085b4 ("lightnvm: do not remove instance under global lock")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 410

2019-06-05T15:37:14+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details you should have received a copy of the gnu general
  public license along with this program see the file copying if not
  write to the free software foundation 675 mass ave cambridge ma
  02139 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 3 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190112.675111872@linutronix.de
Signed-off-by: Greg Kroah-Hartman

lightnvm: do not remove instance under global lock

2019-05-06T16:19:19+00:00

Currently all the target instances are removed under global nvm_lock.
This was needed to ensure that nvm_dev struct will not be freed by
hot unplug event during target removal. However, current implementation
has some drawbacks, since the same lock is used when new nvme subsystem
is registered, so we can have a situation, that due to long process of
target removal on drive A, registration (and listing in OS) of the
drive B will take a lot of time, since it will wait for that lock.

Now when we have kref which ensures that nvm_dev will not be freed in
the meantime, we can easily get rid of this lock for a time when we are
removing nvm targets.

Signed-off-by: Igor Konopko 
Reviewed-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: track inflight target creations

2019-05-06T16:19:19+00:00

When creation process is still in progress, target is not yet on
targets list. This causes a chance for removing whole lightnvm
subsystem by calling nvm_unregister() in the meantime and finally by
causing kernel panic inside target init function.

This patch changes the behaviour by adding kref variable which tracks
all the users of nvm_dev structure. When nvm_dev is allocated, kref
value is set to 1. Then before every target creation the value is
increased and decreased after target removal. The extra reference
is decreased when nvm subsystem is unregistered.

Signed-off-by: Igor Konopko 
Reviewed-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: prevent race condition on pblk remove

2019-05-06T16:19:18+00:00

When we trigger nvm target remove during device hot unplug, there is
a probability to hit a general protection fault. This is caused by use
of nvm_dev thay may be freed from another (hot unplug) thread
(in the nvm_unregister function).

Introduce lock in nvme_ioctl_dev_remove function to prevent this
situation.

Signed-off-by: Marcin Dziegielewski 
Reviewed-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: Inherit mdts from the parent nvme device

2019-05-06T16:19:17+00:00

Current lightnvm and pblk implementation does not care about NVMe max
data transfer size, which can be smaller than 64*K=256K. There are
existing NVMe controllers which NVMe max data transfer size is lower
that 256K (for example 128K, which happens for existing NVMe
controllers which are NVMe spec compliant). Such a controllers are not
able to handle command which contains 64 PPAs, since the the size of
DMAed buffer will be above the capabilities of such a controller.

Signed-off-by: Igor Konopko 
Reviewed-by: Hans Holmberg 
Reviewed-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: dynamic DMA pool entry size

2018-12-11T19:22:35+00:00

Currently lightnvm and pblk uses single DMA pool, for which the entry
size always is equal to PAGE_SIZE. The contents of each entry allocated
from the DMA pool consists of a PPA list (8bytes * 64), leaving
56bytes * 64 space for metadata. Since the metadata field can be bigger,
such as 128 bytes, the static size does not cover this use-case.

This patch adds support for I/O metadata above 56 bytes by changing DMA
pool size based on device meta size and allows pblk to use OOB metadata
>=16B.

Reviewed-by: Javier González 
Signed-off-by: Igor Konopko 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: simplify geometry enumeration

2018-12-11T19:22:34+00:00

Currently the geometry of an OCSSD is enumerated using a two step
approach:

First, nvm_register is called, the OCSSD identify command is issued,
and second the geometry sos and csecs values are read either from the
OCSSD identify if it is a 1.2 drive, or from the NVMe namespace data
structure if it is a 2.0 device.

This patch recombines it into a single step, such that nvm_register can
use the csecs and sos fields independent of which version is used. This
enables one to dynamically size the lightnvm subsystem dma pool.

Reviewed-by: Igor Konopko 
Reviewed-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: Fix uninitialized return value in nvm_get_chunk_meta()

2018-12-11T19:22:33+00:00

With gcc 4.1:

    drivers/lightnvm/core.c: In function ‘nvm_get_bb_meta’:
    drivers/lightnvm/core.c:977: warning: ‘ret’ may be used uninitialized in this function

and

    drivers/nvme/host/lightnvm.c: In function ‘nvme_nvm_get_chk_meta’:
    drivers/nvme/host/lightnvm.c:580: warning: ‘ret’ may be used uninitialized in this function

Indeed, if (for the former) the number of channels or LUNs is zero, or
(for both) the passed number of chunks is zero, ret will be returned
uninitialized.

Fix this by preinitializing ret to zero.

Fixes: aff3fb18f957de93 ("lightnvm: move bad block and chunk state logic to core")
Fixes: a294c199455187d1 ("lightnvm: implement get log report chunk helpers")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

block: remove the lock argument to blk_alloc_queue_node

2018-11-15T19:13:35+00:00

With the legacy request path gone there is no real need to override the
queue_lock.

Reviewed-by: Hannes Reinecke 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe