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:
signature.asc
Description: PGP signature
