From: Martin Wilck <mwilck@suse.com>
To: Peter Rajnoha <prajnoha@redhat.com>,
Zdenek Kabelac <zkabelac@redhat.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
David Teigland <teigland@redhat.com>
Cc: linux-lvm@lists.linux.dev, dm-devel@lists.linux.dev,
Hannes Reinecke <hare@suse.de>
Subject: Re: [RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1
Date: Mon, 04 Mar 2024 17:09:22 +0100 [thread overview]
Message-ID: <044ce4d6dad7873de1104568e5bd86361997d073.camel@suse.com> (raw)
In-Reply-To: <b884374b-2f6f-4c7f-acba-b4c730ae03ff@redhat.com>
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
next prev parent reply other threads:[~2024-03-04 16:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 22:40 [RFC PATCH 0/7] device mapper udev rules rework Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 1/7] 13-dm-disk.rules: import ID_FS_TYPE Martin Wilck
2024-03-04 10:37 ` Peter Rajnoha
2024-03-04 15:17 ` Martin Wilck
2024-03-04 15:44 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1 Martin Wilck
2024-03-04 10:48 ` Peter Rajnoha
2024-03-04 11:19 ` Peter Rajnoha
2024-03-04 11:27 ` Peter Rajnoha
2024-03-04 15:21 ` Martin Wilck
2024-03-04 16:09 ` Martin Wilck [this message]
2024-03-05 8:09 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 3/7] 10-dm-rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db Martin Wilck
2024-03-04 10:49 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 4/7] 11-dm-lvm.rules: " Martin Wilck
2024-03-04 10:51 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 5/7] dm udev rules: don't export and save DM_SUSPENDED Martin Wilck
2024-03-04 11:00 ` Peter Rajnoha
2024-03-04 16:21 ` Martin Wilck
2024-03-05 8:19 ` Peter Rajnoha
2024-03-05 8:47 ` Martin Wilck
2024-03-05 9:10 ` Peter Rajnoha
2024-03-05 9:28 ` Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 6/7] dm udev rules: don't export and save DM_NOSCAN Martin Wilck
2024-03-04 11:03 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 7/7] 10-dm.rules: bump DM_UDEV_RULES_VSN to 3 Martin Wilck
2024-03-04 11:09 ` Peter Rajnoha
2024-03-04 16:46 ` Martin Wilck
2024-03-05 8:26 ` Peter Rajnoha
2024-03-05 9:04 ` Martin Wilck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=044ce4d6dad7873de1104568e5bd86361997d073.camel@suse.com \
--to=mwilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.de \
--cc=linux-lvm@lists.linux.dev \
--cc=prajnoha@redhat.com \
--cc=teigland@redhat.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).