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