On Mon, Dec 15, 2008 at 18:59, Scott James Remnant <scott@xxxxxxxxxxxxx> wrote: > On Mon, 2008-12-15 at 18:19 +0100, Kay Sievers wrote: > >> On Mon, Dec 15, 2008 at 18:18, Scott James Remnant <scott@xxxxxxxxxxxxx> wrote: >> > On Mon, 2008-12-15 at 18:14 +0100, Kay Sievers wrote: >> > >> >> Yep, and they are racy, we discussed that at the time you did that. It >> >> seems to work fine for you though, which is good. But I didn't want to >> >> add that any enterprise release, which we would need to support for >> >> many years. Device-mapper needs _proper_ udev integration, not a >> >> "overwrite each-other and the last one wins" solution. :) >> >> >> > I don't agree that there's any race here. >> >> Should be all in the archives, you never responded that time to my concerns. :) >> > I could only find one concern noted, which the code proves is incorrect. > Assuming you mean the time period between stat() and rename(), one or > the other of the syscalls with fail - and both udev and devmapper will > loop and repair the situation. Yeah, it was something like that. If I remember correctly, also the setting of the permissions and the selinux context. We added the parts of these changes of udev, to support such a logic. But the libdevmapper part didn't look like it covered the possible races, especially rename dm-rename events, and the case where /dev/mapper/ are symlinks, like they should be in a udev setup. Even when it usually does not fail in real world setups, in general it's nothing that we want to support: two independent processes without synchronization, fight about the same files in /dev. Libdevmapper just needs to synchronize/integrate with udev in a race-free way instead. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
