By the previous commit, it is not necessary to distinguish if the devlink
already exists. Also, I cannot find any significant advantages of the
previous complecated logic, that is, first try to create directly, and then
fallback to atomically creation. Moreover, such logic increases the chance
of conflicts between multiple udev workers.
This makes devlinks always created atomically. Hopefully, this reduces the
conflicts between the workers.
During creating a symlink to a device node, if another device node which
requests the same symlink is added/removed, `stat_inode_unmodified()`
should always detects that. We do not need to continue the loop
unconditionally.
Previously, we only store device IDs in /run/udev/links, and when
creating/removing device node symlink, we create sd_device object
corresponds to the IDs and read device node and priority from the
object. That requires parsing uevent and udev database files.
This makes link_find_prioritized() get the most prioritzed device node
without parsing the files.
This makes the last 11 chars are always preserved for hashed string.
So, it is hard to generate a path which conflicts to another path.
Fixes an issue demonstrated in the previous commit.
Previously it was very likely, when multiple contenders for the symlink
appear in parallel, that algorithm would select wrong symlink (i.e. one
with lower-priority).
Now the algorithm is much more defensive and when we detect change in
set of contenders for the symlink we reevaluate the selection. Same
happens when new symlink replaces already existing symlink that points
to different device node.
Let's open the device node to modify with O_PATH, and then adjust it
only after verifying everything is in order. This fixes a race where the
a device appears, disappears and quickly reappers, while we are still
running the rules for the first appearance: when going by path we'd
possibly adjust half of the old and half of the new node. By O_PATH we
can pin the node while we operate on it, thus removing the race.
Previously, we'd do a superficial racey check if the device node changed
undearneath us, and would propagate EEXIST in that case, failing the
rule set. With this change we'll instead gracefully handle this, exactly
like in the pre-existing case when the device node disappeared in the
meantime.
This partially reverts 25de7aa7b9. I don't think the
change was intended there.
The problem I'm trying to solve: for /dev/kvm we get first an ADD uevent, and
then CHANGE whenever something connects or disconnects to the character device.
The rules in 50-default-udev.rules set UID, GID, and MODE on ADD, but not on
CHANGE. When the change event happens, we would reset the ownership and
permissions.
This happens because node_permissions_apply() would (after 25de7aa7b9)
set uid=gid=0 if they weren't set by the rules.
So let's only pass uid/gid/mode to node_permissions_apply() if appropriately
configured. Also let node_permissions_apply() do the skip of uid/gid/mode if
not set, and rename "always_apply" to more closely reflect its meaning.
This fixes bugs introduced by 29448498c7
and d838e14515.
Previously, RUN and SECLABEL keys are stored in udev_list with its unique
flag is false. If the flag is false, then udev_list is just a linked
list and new entries are always added in the last.
So, we should use OrderedHashmap instead of Hashmap.
Fixes#11368.
Yu Watanabe
Franck Bui
Zbigniew Jędrzejewski-Szmek
Michal Sekletár
Lennart Poettering