| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Propagating $NOTIFY_SOCKET is typically dangerous. Let's unset it unless
explicitly requested to keep it.
Fixes #27288.
Replaces #27291.
|
| |
|
|
|
|
|
|
|
|
|
| |
This effectively reverts commit ff86c92e3043f71fc801cf687600a480ee8f6778,
and re-apply 49f3ee7e74c714f55aab395c080b1099fc17f7fd.
The change was dropped due to the process name was not correctly logged,
but the issue was fixed by dd15e4cb57129b915e01495e113696bfe0b70214.
Let's set the child process name again.
|
|
|
|
|
|
| |
We are basically already there, just need to add MONOTONIC_USEC= to the
RELOADING=1 message, and make sure the message is generated in really
all cases.
|
| |
|
|
|
|
| |
In some places, initialization is dropped when unnecesary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
|
| |
|
|
|
|
| |
Follow-up for f714ecd450828e45a6f04e6277011d67a10c323f.
|
|
|
|
|
| |
We check the same list of error codes on various xattr operations, and
we should on some more. Add a common helper for this purpose.
|
|
|
|
|
|
|
|
| |
No functional changes, just refactoring.
Note, this also makes synthesize_change() propagate the error from
synthesize_change_one(). However, the caller of synthesize_change()
ignores the failure anyway, hence the change does not take any effect.
|
|
|
|
|
|
| |
We already checked that the sd_device object 'dev' is for a whole block
device. So, -ENOENT should not be triggeered here, and if it is, there
exists something spurious. Hence we should not ignore the failure.
|
|
|
|
| |
This should not change anything effectively.
|
|\
| |
| | |
udev: open with O_NOCTTY
|
| |
| |
| |
| |
| | |
All files or device nodes opened here should not be console tty.
Let's open it the flags for safety.
|
| | |
|
|\ \
| | |
| | | |
udev: resolve race in saving inotify watch handle
|
| | |
| | |
| | |
| | | |
As it is already called by udev_event_execute_rules().
|
| | | |
|
| |/ |
|
|\ \
| |/
|/| |
udev-node: use flock() for symlink stack directory
|
| |
| |
| |
| |
| |
| | |
By the previous commit, the stack directories are not removed even if
it is empty. To reduce the inode usage of /run, let's cleanup the
directories.
|
| |
| |
| |
| | |
No functional changes, just refactoring.
|
|/
|
|
| |
No functional changes, just refactoring.
|
|
|
|
|
|
| |
assigned
Also refuse invalid log level.
|
|
|
|
|
|
|
| |
As the subsequent call of on_post() will call it if necessary.
This also drop unnecessary call of event_source_disable() for killing
idle workers, as the event source is disabled in event_queue_start().
|
|
|
|
|
|
|
|
|
|
|
|
| |
If udevd receives a uevent for a locked block device, then the event
is requeued. However, the queued event will be processed only when at
least one sd_event_source is processed. Hence, if udevd has no event
under processing, or receives no new uevent, etc., then the requeued
event will be never processed.
Follow-up for 400e3d21f8cae53a8ba9f9567f244fbf6f3e076c.
Fixes #24439.
|
|
|
|
| |
Follow-up for 5d354e525a56955ae7f68062e283dda85ab07794.
|
|
|
|
|
|
| |
Previously, true by validate() means several configs are outdated and we
need to reload configs. That's not intuitive for me. Let's rename the
functions.
|
| |
|
|
|
|
|
|
|
| |
This makes udevd reload rules only when the timestamp is updated,
even on SIGHUP or `udevadm control --reload`.
So, we can call `udevadm control --reload` without huge performance
penalty when no rules, .link files, and so on are changed.
|
|
|
|
|
| |
The mtime of directory is not updated when an existing rule file is
changed. Hence, paths_check_timestamp() is not reliable.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
basic/list: drop LIST_IS_EMPTY
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was a trivial wrapper that didn't provide any added value. With more
complicated structures like strvs, hashmaps, sets, and arrays, it is possible
to have an empty container. But in case of a list, the list is empty only when
the head is missing.
Also, we generally want the positive condition, so we replace many
if (!LIST_IS_EMPTY(x)) with just if (x).
|
|\ \
| |/
|/| |
udev: cleanups for event blocker
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even if the device node is the same, devnum (thus, device ID) and
syspath may be different. If a 'remove' and 'add' events for the same
device node but with different devnum and syspath are queued,
previously, we might process them in parallel. And, udev_watch_end() for
the 'remove' event and udev_watch_begin() for the 'add' event may
interfere each other.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, a device has DEVPATH_OLD is blocked by a previous event
whose devpath is equivalent to the DEVPATH_OLD.
This extends the condtion.
1. an event has DEVPATH_OLD is blocked by a previous event whose
devpath is a parent of, child of, or equivalent to the DEVPATH_OLD.
2. an event is blocked by a previous event whose DEVPATH_OLD is a
parent of, child of, or equivalent to the devpath of the new event.
I am not sure such check is really necessary. But, the cost of the check
is expected to be extremely small, as device renaming does not occur so
frequently. Hence, it should not introduce any significant performance
regression.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If two devices have the same devnum and subsystem (more specifically,
if the device is block or not), or have the same ifindex, then IDs of
these devices are equivalent.
Hence, the previous conditions are covered by comparing device IDs.
Of course, events with a same ID should be already blocked by the
devpath check. So, this should not change anything.
However, udevd saves many kinds of data under /run/udev named with
the device ID. If multiple workers processes events for the same device
ID, then the database may become corrupted.
Let's explicitly check the device IDs for safety and simplicity.
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
This also adds EVENT_RESULT_SUCCESS for readability.
|
|
|
|
|
|
| |
I am not sure whether the original discussions are correct or not.
This is just for adding references for future verification for the
filters.
|
| |
|
| |
|