[PATCH] nvme: generate uevent once a multipath namespace is operational again

[Hannes Reinecke]

On 5/6/21 9:37 AM, Christoph Hellwig wrote:
> On Wed, May 05, 2021 at 12:33:05PM +0200, Hannes Reinecke wrote:
>> In an all paths down scenario I/O will be requeued or aborted, so no
>> further I/O will be ongoing on this namespace.
>> This leaves upper layers like MD unable to determine if the namespace
>> becomes operational again after a successful controller reset.
>> This patch will send an uevent per multipathed namespace once the
>> underlying controller is LIVE, allowing MD to start resync.
> 
> Do we have any documentation or other exampes for this KOBJ_CHANGED
> magic?  I've seen it in a few places, but it always seemed rather
> cargo cult to me.  If you have a more insights any chance you could
> document it?
> 
It's precisely cargo cult, but definitely not well documented.

Currently there is an ambiguity between 'KOBJ_ADD' and 'KOBJ_CHANGED';
some devices will only send KOBJ_ADD, other (most notably S/390 DASDs
and device-mapper devices) will send KOBJ_CHANGED to indicate that this
device is now live and ready for use.
Sadly there is no indicator telling you if that particular device
implements KOBJ_CHANGED at all, so one really has to know what to look
out for.
But the general rule is that 'KOBJ_CHANGED' indicates that a device is
not ready for use; KOBJ_ADD indicates that a device has been added to
the system and _might_ indicate that the device is ready to use.

>> +		if (ctrl->state == NVME_CTRL_LIVE)
>> +			kobject_uevent(&disk_to_dev(ns->head->disk)->kobj,
>> +				       KOBJ_CHANGE);
> 
> Also this should probably use disk_uevent to also notify partitions.
> Maybe also for other existing callers.
> 
Indeed, you are correct. Will be fixing it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		        Kernel Storage Architect
hare at suse.de			               +49 911 74053 688
SUSE Software Solutions Germany GmbH, 90409 Nürnberg
GF: F. Imendörffer, HRB 36809 (AG Nürnberg)