On Mon, 2024-03-04 at 11:48 +0100, Peter Rajnoha wrote: > > Yes, I'd like to get rid of this rule, but, unfortunately, there's > one > issue during the DM device creation/activation. > > For example, if I try: > > dmsetup create --readonly --table "0 1 zero" > > Then I get these uevents: > > 1) > ACTION=add > DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 > DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 > DM_UDEV_DISABLE_DISK_RULES_FLAG=1 > SYSTEMD_READY=0 > > > 2) > ACTION=change > DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 > DM_UDEV_DISABLE_DISK_RULES_FLAG=1 > DM_UDEV_DISABLE_OTHER_RULES_FLAG= > > > 3) > ACTION=change > DM_COOKIE=6335392 > DM_COOKIE_DISABLE_OTHER_RULES_FLAG= > > > The uevent 3) coming with the DM_COOKIE is the actual event when the > device is ready for use (that's the uevent notifying the DM device > resume/activation). > > If we remove the DISK_RO rule, then the > DM_UDEV_DISABLE_OTHER_RULES_FLAG > is unset for uevent 2), which in turn causes the SYSTEMD_READY=0 to > get > dropped, which in turn will start all the systemd hooks because the > device is considered "ready" for systemd then. > But the DM dev is ready only after uevent 3) that comes with the > DM_COOKIE. So we still need to cover this scenario. As event 2) doesn't have DM_COOKIE, I don't think we need to bother about it much. IMO we should treat it like a synthetic "change" event, which has almost no effect as far as dm is concerned. Event 3) doesn't have DISK_RO=1 set. If any later rules are interested in the state of write protection, they need to check the "ro" sysfs attribute instead. It would make some sense to be able tell later rules that they don't need to bother with a given uevent because (from device mapper PoV) nothing relevant has changed. I am not sure if we should use DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 for this purpose. "Don't bother, nothing has changed" is not the same thing as "don't bother, you can't access this device right now", which to my understanding is the meaning of DM_UDEV_DISABLE_OTHER_RULES_FLAG=1. Actually we have DM_ACTIVATION=1 to tell other rules that they do need to take action. Later rules only need to rescan a DM device if DM_ACTIVATION=1; in all other cases they could just import properties from the db. Currently kpartx and lvm are the only rules that check DM_ACTIVATION. Regards Martin
