[PATCHv4] nvme: allow to re-attach namespaces after all paths are down

[Sagi Grimberg]

>>> On Mon, May 17, 2021 at 10:18:09AM +0200, Hannes Reinecke wrote:
>>>> We should only remove the ns head from the list of heads per
>>>> subsystem if the reference count drops to zero. Removing it
>>>> at the start of nvme_ns_remove() will prevent us from reattaching
>>>> the namespace to the correct ns head once a path becomes available
>>>> again.
>>>
>>> This looks fine to me
>>>
>>> Reviewed-by: Keith Busch <kbusch at kernel.org>
>>>
>>> There are potential corner cases associated with namespace management
>>> that can cause problems here, but it would certainly be a user error
>>> that needs manual intervention anyway. I suspect those scenarios are
>>> very uncommon too, so I think we can deal with that later if it becomes
>>> a problem.
>>>
>> How so?
>> We're keeping a copy of the NS IDs around, so after reconnect the
>> namespace would have to provide same set of NS IDs.
>>
>> If the namespace is different yet providing the same NS IDs we'll have a
>> problem even with the current code, as we're using the ND ID to identify
>> multipathed namespaces.
>>
>> Or do you have a different scenario in mind?
> 
> Sorry, I didn't mean to imply this creates a new problem. It's already a
> problem. :)
> 
> This just provides a chance for a recycled ID for a newly created
> namespace to attach to an in-use head associated with a previously
> deleted namespace. I am not really concerned about this scenario,
> though, since it wouldn't work today anyway.

That is because we keep the device node around even though it doesn't
have any bottom devices. Which is what I think Hannes tried to fix
in an earlier patch.

Also, if an NVM subsystem happens to recycle nsids, it will trigger
pretty surely. So I'm not sure this is an obscure case...