Re: [PATCH] md: Drop sending a change uevent when stopping

From: NeilBrown <neilb@suse.com>
To: Hannes Reinecke <hare@suse.de>, Shaohua Li <shli@kernel.org>,
	Sebastian Parschauer <sebastian.riemer@profitbricks.com>
Cc: linux-raid <linux-raid@vger.kernel.org>,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	Artur Paszkiewicz <artur.paszkiewicz@intel.com>,
	Brassow Jonathan <jbrassow@redhat.com>,
	systemd-devel@freedesktop.org
Subject: Re: [PATCH] md: Drop sending a change uevent when stopping
Date: Fri, 19 Feb 2016 10:06:20 +1100	[thread overview]
Message-ID: <87egc9pqj7.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <56C56894.8070906@suse.de>

[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

On Thu, Feb 18 2016, Hannes Reinecke wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/17/2016 10:29 PM, NeilBrown wrote:
>> On Thu, Feb 18 2016, Shaohua Li wrote:
>> 
>>> On Wed, Feb 17, 2016 at 05:25:00PM +0100, Sebastian
>>> Parschauer wrote:
>>>> When stopping an MD device, then its device node /dev/mdX
>>>> may still exist afterwards or it is recreated by udev. The
>>>> next open() call can lead to creation of an inoperable MD
>>>> device. The reason for this is that a change event
>>>> (KOBJ_CHANGE) is sent to udev which races against the
>>>> remove event (KOBJ_REMOVE) from md_free(). So drop sending
>>>> the change event.
>>>> 
>>>> A change is likely also required in mdadm as many versions
>>>> send the change event to udev as well.
>>> 
>>> Makes sense, it's unlikely we need the CHANGE event.
>>> Applied.
>>> 
>>> Thanks, Shaohua
>> 
>> It would be worth checking, but I think that with this change,
>> you can write "inactive" to /sys/block/mdXXX/md/array_state and
>> the array will become inactive, but no uevent will be
>> generated, which isn't good. Maybe send the uevent that was
>> just removed from the 'inactive' case of array_state_store()
>> instead.
>> 
>> (But I still think this is just a bandaid and doesn't provide
>> any guarantees that there will be no races with udev)
>> 
> Thing is, _none_ of the other subsystems will ever send a uevent
> when it becomes inactive.

A CDROM drive does when you eject the media.

> (Would be pretty pointless, too, as what exactly is one supposed
> to do here?)

Lazy-unmount the filesystem?
If the array was part of another array, mark the slot in that array as
'faulty' ?

> The current usage has it that CHANGE events are only ever sent if
> a device becomes active.

"mostly" but not "only ever".

Thanks,
NeilBrown

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 172 bytes --]

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel