[PATCH RFC 3/5] NVMe: Asynchronous device scan support

[willy@linux.intel.com (Matthew Wilcox)]

On Fri, Mar 28, 2014@07:32:54PM +0530, Santosh Y wrote:
> On Mon, Dec 30, 2013@7:20 PM, Matthew Wilcox <willy@linux.intel.com> wrote:
> > On Mon, Dec 30, 2013@03:57:18PM +0530, Santosh Y wrote:
> >> This patch provides asynchronous device enumeration
> >> capability. The 'probe' need not wait until the namespace scanning is
> >> complete.
> >
> > I'm very interested in having something like this, except I don't think
> > it's complete.  You don't seem to handle the cases where the device
> > is shut down in the middle of an async scan.  Also, the only piece you
> > seem to make async is the calls to add_disk(), which are surely not the
> > timeconsuming parts of the scan.  I would think the time consuming parts
> > are sending the IDENTIFY commands, which you don't make async.
> >
> 
> Would you prefer changes in the following patch. Please let me know
> your comments.

There are a few things I'd like to see done differently.

For motivation, I have a device here which erroneously reports that it
has billions of namespaces.  Every time I forget to include the patch to
change 'nn' to 1 for that PCI device ID, the driver sends billions of
IDENTIFY NAMESPACE commands to that device.  While I wait for that to
happen, it gives me plenty of time to look at the system and think about
the consequences of the code we have today :-)

1. I want to be able to remove the module before the scan has finished.
So the 'wait for the mutex' design you have doesn't work for this case;
we need to be able to interrupt the scan.

2. Right now all of the work is being carried out by a kworker.  Since we
have an nvme kthread, I'd like for that to be doing the work so someone
who doesn't know nvme has a decent chance of figuring out that their
system is misbehaving because nvme is doing something unusual.

3. The system is spewing out lots of nasty messages about tasks hanging
waiting for mutexes, eg:

[  721.687298] INFO: task modprobe:1072 blocked for more than 120 seconds.

The mutex it is waiting for is being held by the upper level code which
has called the nvme driver to initialise.  Therefore we must return from
the nvme driver probe code before scanning namespaces has completed.

4. There is an accepted TP for nvme 1.2 that allows the device to send
an Async Notification that some aspect of the namespace inventory has
changed, and invites us to rescan.  I would love to take that into
account in a patch that overhauls scanning.

5. A really good patch would also try to use the nvme 1.1 capability to
report sparse namespaces (IDENTIFY with CNS = 2).

6. You need to find a better email program; the one you have is converting
tabs to spaces.