linux/drivers/nvme, branch v4.7

nvme: Remove RCU namespace protection

2016-07-14T15:48:08Z

We can't sleep with RCU read lock held, but we need to do potentially blocking stuff to namespace queues when iterating the list. This patch removes the RCU locking and holds a mutex instead. To prevent deadlocks, this patch removes holding the mutex during namespace scanning and removal. The unlocked namespace scanning is made safe by holding a reference to the namespace being scanned. List iteration that does IO has to be unlocked to allow error recovery. The caller must ensure the list can not be manipulated during such an event, so this patch adds a comment explaining this requirement to the only function that iterates an unlocked list. All callers currently meet this requirement, so no further changes required. List iterations that do not do IO can safely use the lock since it couldn't block recovery from missing forced IO completions. Reported-by: Ming Lin [fixes 0bf77e9 nvme: switch to RCU freeing the namespace] Signed-off-by: Keith Busch Signed-off-by: Jens Axboe

NVMe: Only release requested regions

2016-06-09T20:28:28Z

The NVMe driver only requests the PCIe device's memory regions but releases all possible regions (including eventual I/O regions). This leads to a stale warning entry in dmesg about freeing non existent resources. Signed-off-by: Johannes Thumshirn Signed-off-by: Jens Axboe

nvme/host: Add missing blk_integrity tag_size + flags assignments

2016-05-17T23:14:21Z

While doing recent bring-up of nvme/host with target-core T10-PI, I noticed /sys/block/nvme*/integrity/device_is_integrity_capable was false, and /sys/block/nvme*/integrity/tag_size contained a bogus value. AFAICT outside of blk_integrity_compare() for DM + MD these are informational values, but go ahead and add the missing assignments for nvme/host to match what SCSI does within sd_dif_config_host() for consistency's sake. Cc: Keith Busch Cc: Jay Freyensee Cc: Martin K. Petersen Cc: Sagi Grimberg Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Reviewed-by: Sagi Grimberg Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe

NVMe: Add device ID's with stripe quirk

2016-05-17T23:14:21Z

Adds two Intel controllers that have the "stripe" quirk. Signed-off-by: Keith Busch Signed-off-by: Jens Axboe

NVMe: Short-cut removal on surprise hot-unplug

2016-05-17T23:14:21Z

This patch adds a new state that when set has the core automatically kill request queues prior to removing namespaces. If PCI device is not present at the time the nvme driver's remove is called, we can kill all IO queues immediately instead of waiting for the watchdog thread to do that at its polling interval. This improves scenarios where multiple hot plug events occur at the same time since it doesn't block the pci enumeration for as long. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe

NVMe: Allow user initiated rescan

2016-05-17T23:14:21Z

This exposes ioctl and sysfs methods a user can invoke to request the driver rescan a controller and its namespaces. This is less harsh than doing a controller reset, which temporarilly halts all IO, just to surface a newly attached namespace. This is mainly useful for controllers that implement the namespace management command, but do not support the namespace notify change asynchronous event notification. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe

NVMe: Reduce driver log spamming

2016-05-17T23:14:21Z

Reduce error logging when no corrective action is required. Suggessted-by: Chris Petersen Signed-off-by: Keith Busch Signed-off-by: Jens Axboe

NVMe: Unbind driver on failure

2016-05-17T23:14:21Z

Instead of removing the PCI device from the kernel's topology on controller failure, this patch simply requests unbinding the device from the driver. This avoids concurrently running pci removal with the hot plug event, which has been reported to be problematic when multiple surprise events occur near simultaneously. The other benefit is that we will have PCI config and memory space available to poke around for debugging a failed controller, assuming the device was not physically removed. The down side occurs if the platform and/or kernel do not support any type of surprise hot removal. The device will remain visible through sysfs (and therefore lspci), and some manual work is necessary to get the logical topology corrected. But if your platform and/or kernel don't support surprise removal, you probably shouldn't be doing that anyway. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe

NVMe: Delete only created queues

2016-05-17T23:14:21Z

Use the online queue count instead of the number of allocated queues. The controller should just return an invalid queue identifier error to the commands if a queue wasn't created. While it's not harmful, it's still not correct. Reported-by: Saar Gross Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe

NVMe: Allocate queues only for online cpus

2016-05-17T23:14:21Z

The driver previously requested allocating queues for the total possible number of CPUs so that blk-mq could rebalance these if CPUs were added after initialization. The number of hardware contexts can now be changed at runtime, so we only need to allocate the number of online queues since we can add more later. Suggested-by: Jeff Lien Signed-off-by: Keith Busch Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe