Commits on May 28, 2024

1. 99-systemd.rules: rework SYSTEMD_READY logic for device mapper …

   Device mapper devices are set up in multiple steps. The first step, which
   generates the initial "add" event, only creates an empty container, which is
   useless for higher layers. SYSTEMD_READY should be set to 0 on this event to
   avoid premature device activation.
   
   The event that matters is the "activation" event: the first "change" event on
   which DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 is not set. When this event arrives,
   the device is ready for being scanned by blkid and similar tools, and for being
   activated by systemd.
   
   Intermittent events with DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 should be ignored
   as far as systemd or higher-level block layers are concerned. Previous device
   properties and symlinks should be preserved: the device shouldn't be scanned or
   activated, but shouldn't be deactivated, either.  In particular, SYSTEM_READY
   shouldn't be set to 0 if it wasn't set before, because that might cause mounted
   file systems to be unmounted. Such intermittent events may occur any time,
   before or after the "activation" event.
   
   DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 can have multiple reasons. One possible reason
   is that the device is suspended. There are other reasons that depend on the
   device-mapper subsystem (LVM, multipath, dm-crypt, etc.).
   
   The current systemd rule set
   
   1) sets SYSTEMD_READY=0 if DM_UDEV_DISABLE_OTHER_RULES_FLAG is set in "add"
   events;
   2) imports SYSTEMD_READY from the udev db if DM_SUSPENDED is set, and jumps to systemd_end;
   3) sets SYSTEMD_READY=1, otherwise.
   
   This logic has several flaws:
   
   * 1) can cause file systems to be unmounted if an coldplug event arrives while
   a file system is suspended. This rule shouldn't be applied for coldplug events
   or in general, "synthetic" add events;
   * 2) evaluates DM_SUSPENDED=1, which is a device-mapper internal property.
   It's wrong to infer that a device is accessible if DM_SUSPENDED=0.
   The jump to systemd_end may cause properties and/or symlinks to be lost;
   * 3) is superfluous, because SYSTEMD_READY=1 is equivalent with SYSTEMD_READY
   being unset, and can create the wrong impression that the device was explicitly
   activated.
   
   This patch fixes the logic as follows:
   
   - apply 1) only if DM_NAME is empty, which is only the case for the first
   "genuine add" event;
   - change 2) to use DM_UDEV_DISABLE_OTHER_RULES_FLAG instead of DM_SUSPENDED,
   and remove the GOTO directive;
   - remove 3).
   
   Fixes: b7cf1b6 ("udev: use SYSTEMD_READY to mask uninitialized DM devices")
   Fixes: 35a6750 ("rules: set SYSTEMD_READY=0 on DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 only with ADD event (#2747)")
   
   Signed-off-by: Martin Wilck <mwilck@suse.com>
   (cherry picked from commit c072860)

   

   mwilck committed May 28, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 9a77e2e
   • Browse repository at this point

   Copy the full SHA

   9a77e2e View commit details

   Browse the repository at this point in the history