On Fri, Feb 19, 2016 at 10:06:20AM +1100, Neil Brown wrote: > 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". Neil, did you mean I should drop the patch? I really doubt there is any difference with/without the CHANGE event giving a REMOVE event will pop up soon. But this could be userspace aware, I'm not totally sure. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
