Age | Commit message (Collapse) | Author |
|
Harald Hoyer discovered some incorrect behavior while debugging
problems with network interface renaming:
Udev events might be queued for devices which are renamed. A new
device registered the same time may claime the old name and create
a database entry for it. The current rename logic would move over
this databse entry to the wrong device.
|
|
|
|
CC udev/udevd.o
In file included from udev/udev.h:27,
from udev/udevd.c:47:
./libudev/libudev-private.h: In function ‘udev_selinux_setfscreateconat’:
./libudev/libudev-private.h:230: warning: declaration of ‘dirfd’ shadows a global declaration
/usr/include/dirent.h:224: warning: shadowed declaration is here
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
|
|
|
|
|
|
Thanks to Lennart for finding this.
|
|
|
|
|
|
|
|
|
|
We an empty or garbage-collected queue file, we might not have a record
for the first sequence we wait for, and therefore must not wait for it.
|
|
|
|
|
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We can not predict the major/minor of non-existing devices:
$ grep . /sys/class/block/sd*/dev
/sys/class/block/sda1/dev:259:524288
/sys/class/block/sda2/dev:259:262144
/sys/class/block/sda3/dev:259:786432
/sys/class/block/sda4/dev:259:131072
/sys/class/block/sda/dev:259:0
/sys/class/block/sdb/dev:259:655360
/sys/class/block/sdc/dev:259:393216
If this functionality is still needed for some broken hardware, it needs to be
solved with a tool not part of the udev package. Because such option is unreliable
and unsafe to use.
|
|
|
|
|
|
|
|
|
|
|
|
Recent udisks versions, for LVM2 integration, ships with probers that
produce very long lines such as
UDISKS_LVM2_PV_VG_PV_LIST=
uuid=98lyZl-Ya7U-p26Z-Ia7b-xf8u-xZqP-jc4njb;size=2000397795328;allocated_size=2000397795328
uuid=iFs0cM-sxCF-ceQK-hZl1-kbwo-ZTjq-gSewQR;size=2000397795328;allocated_size=2000397795328
[...]
e.g. roughly 100 bytes per LVM2 physical volume for each LVM2
PV encountered.
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
Otherwise we'll overflow the buffer if space is tight. Also add a comment explaining this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
This function is useful for anything that's likely to be running
alongside udevd during cold-plugging, and is using libudev to
receive the events.
It makes little sense for it to be private, or to require other
software to relearn how to adjust the buffer size.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
|
|
We need to prevent that libudev parses half-written database files.
Also for "change" events, we need to make sure, that database files
always exist to be read by libudev, and that they are not first deleted
before they are re-created.
|
|
|
|
|
|
The move_later_prefix variable was reset to zero on each
loop iteration, and thus the move_later entry (if any) was
not added right after changing to another syspath prefix,
but rather after exiting the enumeration loop.
|
|
It handles only RUN but not IMPORT and PROGRAM. There is no sane way
to suppress program execution. Most important programs run with IMPORT
these days. Also events can no longer suppressed with the libudev
netlink messages, so UDEV_RUN does nothing useful and is just
inconsistent.
|
|
|
|
|
|
Check property match earlier, to avoid lots of readlink() and stat()
calls when we check property matches.
|
|
|
|
When libudev.h is included from C++ code, wrap the declarations in an
extern "C" { ... } block. This tells the C++ compiler that symbols
are exported with C linkage and no name-mangling.
|
|
|
|
|
|
devtype can be NULL, in which case it is ignored for matching.
|
|
These retry loops are required where create_path() could race with
delete_path(). But only the main udevd process writes to the queue,
so no races will happen here.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
|
|
|
|
Dangling symlinks in path components return -ENOENT. Do not retry
to create the file in a loop in such case.
|
|
|