From: Martin Wilck <mwilck@suse.com> To: Zdenek Kabelac <zdenek.kabelac@gmail.com>, Peter Rajnoha <prajnoha@redhat.com> Cc: Franck Bui <fbui@suse.de>, lvm-devel@redhat.com, dm-devel@redhat.com, David Teigland <teigland@redhat.com>, Zdenek Kabelac <zkabelac@redhat.com>, Heming Zhao <heming.zhao@suse.com> Subject: Re: [dm-devel] [PATCH] udev: create symlinks and watch even in suspended state Date: Tue, 01 Feb 2022 11:55:46 +0100 [thread overview] Message-ID: <5342a690855f0047efd9eede5499227246e3fb08.camel@suse.com> (raw) In-Reply-To: <cc5c503a-c94f-d32f-9f91-e388f36c647c@gmail.com> On Tue, 2022-02-01 at 11:11 +0100, Zdenek Kabelac wrote: > > > > > > But yes, if temporarily losing the symlink causes issues, your > > > patch > > > solves that (Zdenek will push that upstream). > > > > Thank you very much! It occured to me that if we want to solve my > > use > > case with minimal risk, we could make the the case in which the > > symlinks are preserved conditional on ACTION=="add" (i.e. true > > coldplug > > events). Tell me if you'd prefer that, I can re-submit. > > The problem is handling of 'suspended' state in udev rules - as I've > mentioned > original no userland tool should mostly care about this. > > However since there are those things like udev 'trigger' and it would > be kind > of ugly if the 'left-over' suspended device would stop whole system > operation > it's most likely better ATM to have some kind of support for this. > > It's should be noted there is still 'race' risk of system freezing in > the case > the suspend happens just after sysfs test and before actual i.e. > 'blkid' use. Right. Even if blkid was smart enough to check immediately before doing I/O on the device, there would still be a race window. It occured to me that it might be useful if IO on suspended DM devices failed with -EAGAIN when opened with a non-blocking file descriptor. But I haven't thought it through ... I suppose that would have other issues, it would be a breaking change anyway. The good thing is that most of the time, the devices are suspended only for a short period of time, so blkid will just hang for a few fractions of a second. The fact that udev skips calling blkid is only for the very rare remaining cases in which the suspend state persists for a long time. > The missed issue to be solve is - that ALL rules have to rely on a > single > suspend check - otherwise we risk 'partial' processing which is the > last > thing we want to see (aka all or nothing). Don't we have that already? Isn't that the check that sets the DM_SUSPENDED flag? > Your real problem was not the suspend on its own - which still may > happen > anytime (so i.e. just after the test whether device is suspended), > but the bug was related to bad exit path cleaning udev db content in > this case > - which is clear bug. Next bug is that other rules have to be > consistent and > properly skip its processing if the 1st. rules decides its meant to > be skipped. Part of the consistency problem is that we have a lot of related but not equivalent udev variables: DM_SUSPENDED DM_NOSCAN DM_UDEV_DISABLE_OTHER_RULES_FLAG DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG DM_UDEV_DISABLE_DISK_RULES_FLAG and then of course SYSTEMD_READY MPATH_DEVICE_READY For consumers of these variables (i.e. udev rules from other subsystems), it's not always obvious which one they should look at (just my €0.02). Regards, Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Martin Wilck <mwilck@suse.com> To: lvm-devel@redhat.com Subject: [PATCH] udev: create symlinks and watch even in suspended state Date: Tue, 01 Feb 2022 11:55:46 +0100 [thread overview] Message-ID: <5342a690855f0047efd9eede5499227246e3fb08.camel@suse.com> (raw) In-Reply-To: <cc5c503a-c94f-d32f-9f91-e388f36c647c@gmail.com> On Tue, 2022-02-01 at 11:11 +0100, Zdenek Kabelac wrote: > > > > > > But yes, if temporarily losing the symlink causes issues, your > > > patch > > > solves that (Zdenek will push that upstream). > > > > Thank you very much! It occured to me that if we want to solve my > > use > > case with minimal risk, we could make the the case in which the > > symlinks are preserved conditional on ACTION=="add" (i.e. true > > coldplug > > events). Tell me if you'd prefer that, I can re-submit. > > The problem is handling of 'suspended' state in udev rules - as I've > mentioned > original no userland tool should mostly care about this. > > However since there are those things like udev 'trigger' and it would > be kind > of ugly if the 'left-over' suspended device would stop whole system > operation > it's most likely better ATM to have some kind of support for this. > > It's should be noted there is still 'race' risk of system freezing in > the case > the suspend happens just after sysfs test and before actual i.e. > 'blkid' use. Right. Even if blkid was smart enough to check immediately before doing I/O on the device, there would still be a race window. It occured to me that it might be useful if IO on suspended DM devices failed with -EAGAIN when opened with a non-blocking file descriptor. But I haven't thought it through ... I suppose that would have other issues, it would be a breaking change anyway. The good thing is that most of the time, the devices are suspended only for a short period of time, so blkid will just hang for a few fractions of a second. The fact that udev skips calling blkid is only for the very rare remaining cases in which the suspend state persists for a long time. > The missed issue to be solve is - that ALL rules have to rely on a > single > suspend check - otherwise we risk 'partial' processing? which is the > last > thing we want to see (aka all or nothing). Don't we have that already? Isn't that the check that sets the DM_SUSPENDED flag? > Your real problem was not the suspend on its own - which still may > happen > anytime (so i.e. just after the test whether device is suspended), > but the bug was related to bad exit path cleaning udev db content in > this case > - which is clear bug.? Next bug is that other rules have to be > consistent and > properly skip its processing if the 1st. rules decides its meant to > be skipped. Part of the consistency problem is that we have a lot of related but not equivalent udev variables: DM_SUSPENDED DM_NOSCAN DM_UDEV_DISABLE_OTHER_RULES_FLAG DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG DM_UDEV_DISABLE_DISK_RULES_FLAG and then of course SYSTEMD_READY MPATH_DEVICE_READY For consumers of these variables (i.e. udev rules from other subsystems), it's not always obvious which one they should look at (just my ?0.02). Regards, Martin
next prev parent reply other threads:[~2022-02-01 10:56 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-28 13:42 [dm-devel] [PATCH] udev: create symlinks and watch even in suspended state mwilck 2022-01-28 13:42 ` mwilck 2022-01-28 15:33 ` [dm-devel] " Zdenek Kabelac 2022-01-28 15:33 ` Zdenek Kabelac 2022-01-28 15:57 ` [dm-devel] " Martin Wilck 2022-01-28 15:57 ` Martin Wilck 2022-01-28 16:02 ` [dm-devel] " Martin Wilck 2022-01-28 16:02 ` Martin Wilck 2022-01-28 17:47 ` [dm-devel] " Zdenek Kabelac 2022-01-28 17:47 ` Zdenek Kabelac 2022-01-28 18:46 ` [dm-devel] " Martin Wilck 2022-01-28 18:46 ` Martin Wilck 2022-01-28 21:06 ` [dm-devel] " Zdenek Kabelac 2022-01-28 21:06 ` Zdenek Kabelac 2022-01-28 23:21 ` [dm-devel] " Martin Wilck 2022-01-28 23:21 ` Martin Wilck 2022-01-29 20:05 ` [dm-devel] " Zdenek Kabelac 2022-01-29 20:05 ` Zdenek Kabelac 2022-01-29 20:46 ` [dm-devel] " Martin Wilck 2022-01-29 20:46 ` Martin Wilck 2022-01-31 13:33 ` [dm-devel] " Peter Rajnoha 2022-01-31 13:33 ` Peter Rajnoha 2022-02-01 8:40 ` [dm-devel] " Martin Wilck 2022-02-01 8:40 ` Martin Wilck 2022-02-01 10:11 ` [dm-devel] " Zdenek Kabelac 2022-02-01 10:11 ` Zdenek Kabelac 2022-02-01 10:55 ` Martin Wilck [this message] 2022-02-01 10:55 ` Martin Wilck 2022-02-01 10:55 ` [dm-devel] " Peter Rajnoha 2022-02-01 10:55 ` Peter Rajnoha 2022-02-01 11:11 ` [dm-devel] " Martin Wilck 2022-02-01 11:11 ` 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=5342a690855f0047efd9eede5499227246e3fb08.camel@suse.com \ --to=mwilck@suse.com \ --cc=dm-devel@redhat.com \ --cc=fbui@suse.de \ --cc=heming.zhao@suse.com \ --cc=lvm-devel@redhat.com \ --cc=prajnoha@redhat.com \ --cc=teigland@redhat.com \ --cc=zdenek.kabelac@gmail.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.