NVMe controller reset

Keith Busch keith.busch at intel.com
Wed Mar 25 08:31:25 PDT 2015


On Wed, 25 Mar 2015, David Sariel wrote:
> Hi Keith,
> Thanks a lot for the prompt and detailed explanations.
> I have fixed the issue with multiple shutdowns and initializations at might
> occur at the same time according to your suggestion.
>
> static int nvme_ioctl(struct block_device *bdev, fmode_t mode, unsigned int cmd,
> 							unsigned long arg)
>
> ...
> case NVME_IOCTL_RESET:
>        ns->dev->reset_workfn = nvme_reset_failed_dev;
>        queue_work(nvme_workq, &ns->dev->reset_work);
> ...

I don't think we want to queue it if it's already running a reset. Just
queue if work_busy(&dev->reset_work) isn't true and return -EBUSY or
block if it is.

Would a user application expect this reset to run asynchronously? I'm
not sure, but if not, we can add a flush_work(&dev->reset_work) at the
end.

And let's make this available only from the management handle's ioctl
nvme_dev_ioctl() rather than a namespace's.

> I can send you a pull request for the addition of the "reset" in the
> nvme-cli. But what do you suggest considering the NVME_IOCTL_RESET addition?
> It can be added to the latest kernel, but actually it comes for pre 3.15
> versions (because on post 3.15 versions echo 1 > /sys/../reset works just
> fine).

Sure, I'll merge nvmecli when the ioctl is applied to the kernel.

I think we should take the ioctl reset so it can be back-ported to
older kernels as well as provide a reset method to virtual devices
that don't get a sysfs entry.



More information about the Linux-nvme mailing list