We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. Issue a warning on
error. Barring an error in the code, the only error that is possible
is ENOSYS.
https://bugzilla.redhat.com/show_bug.cgi?id=1072966
Cases where name_to_handle_at is used allocated the full struct to be
MAX_HANDLE_SZ, and assigned this size to handle_bytes. This is wrong
since handle_bytes should describe the length of the flexible array
member and not the whole struct.
Define a union type which includes sufficient padding to allow
assignment of MAX_HANDLE_SZ to be correct.
The way the kernel namespaces have been implemented breaks assumptions
udev made regarding uevent sequence numbers. Creating devices in a
namespace "steals" uevents and its sequence numbers from the host. It
confuses the "udevadmin settle" logic, which might block until util a
timeout is reached, even when no uevent is pending.
Remove any assumptions about sequence numbers and deprecate libudev's
API exposing these numbers; none of that can reliably be used anymore
when namespaces are involved.
In trying to track down a stupid linker bug, I noticed a bunch of
memset() calls that should be using memzero() to make it more "obvious"
that the options are correct (i.e. 0 is not the length, but the data to
set). So fix up all current calls to memset(foo, 0, length) to
memzero(foo, length).
Uevents are events of the host, which should not leak into a container.
Containers do not support hotplug at the moment, and devices and uevents
are not namespace aware.
Clang is a bit more strict wrt format-nonliterals:
http://clang.llvm.org/docs/LanguageExtensions.html#format-string-checking
Adding these extra printf attributes also makes gcc able to find more
problems. E.g. this patch uncovers a format issue in udev-builtin-path_id.c
Some parts looked intetional about breaking the format-nonliteral check.
I added some supression for warnings there.
Returning anything else but NULL would suggest the caller's reference
might still be valid, but it isn't, because the caller just invoked
_unref() after all.
This turns the return value into a typesafe shortcut that allows
unreffing and resetting a reference in one line. In contrast to
solutions for this which take a pointer to a pointer to accomplish the
same this solution is just syntactic sugar the developer can make use of
but doesn't have to, and this is particularly useful when immediately
unreffing objects returned by function calls.
This extends 62678ded 'efi: never call qsort on potentially
NULL arrays' to all other places where qsort is used and it
is not obvious that the count is non-zero.
In the process, rename udev_encode_string which is poorly named for what
it does. It deals specifically with encoding names that udev creates and
has its own rules: utf8 is valid but some ascii is not (e.g. path
separators), and everything else is simply escaped. Rename it to
encode_devnode_name.
There's now some more obvious overlap amongst the two utf8 validation
functions, but no more than there already was previously.
This also adds some menial tests for anyone who wants to do more
merging of these two in the future.
udev_device_get_subsystem() may return NULL if no subsystem could be
figured out by libudev. This might be due to OOM or if the device
disconnected between the udev_device_new() call and
udev_device_get_subsystem(). Therefore, we need to handle subsystem==NULL
safely.
Instead of testing for it in each helper, we treat subsystem==NULL as
empty subsystem in match_subsystem().
Backtrace of udev_enumerate with an input-device disconnecting in exactly
this time-frame:
(gdb) bt
#0 0x00007ffff569dc24 in strnlen () from /usr/lib/libc.so.6
#1 0x00007ffff56d9e04 in fnmatch@@GLIBC_2.2.5 () from /usr/lib/libc.so.6
#2 0x00007ffff5beb83d in match_subsystem (udev_enumerate=0x7a05f0, subsystem=0x0) at src/libudev/libudev-enumerate.c:727
#3 0x00007ffff5bebb30 in parent_add_child (enumerate=enumerate@entry=0x7a05f0, path=<optimized out>) at src/libudev/libudev-enumerate.c:834
#4 0x00007ffff5bebc3f in parent_crawl_children (enumerate=enumerate@entry=0x7a05f0, path=0x7a56b0 "/sys/devices/<shortened>/input/input97", maxdepth=maxdepth@entry=254) at src/libudev/libudev-enumerate.c:866
#5 0x00007ffff5bebc54 in parent_crawl_children (enumerate=enumerate@entry=0x7a05f0, path=0x79e8c0 "/sys/devices/<shortened>/input", maxdepth=maxdepth@entry=255) at src/libudev/libudev-enumerate.c:868
#6 0x00007ffff5bebc54 in parent_crawl_children (enumerate=enumerate@entry=0x7a05f0, path=path@entry=0x753190 "/sys/devices/<shortened>", maxdepth=maxdepth@entry=256) at src/libudev/libudev-enumerate.c:868
#7 0x00007ffff5bec7df in scan_devices_children (enumerate=0x7a05f0) at src/libudev/libudev-enumerate.c:882
#8 udev_enumerate_scan_devices (udev_enumerate=udev_enumerate@entry=0x7a05f0) at src/libudev/libudev-enumerate.c:919
#9 0x00007ffff5df8777 in <random_caller> () at some/file.c:181
We need to free udev-devices again if they don't match. Funny that no-one
noticed it yet since valgrind is quite verbose about it.
Fix it and free non-matching devices.
If a realloc() happens in syspath_add(), the move_later pointer could
point to an invalid memory region.
Let move_later store the array index, instead of the pointer to the
entry.
clang reports:
src/libudev/libudev-util.c:665:35: warning: cast from
"const unsigned char *" to "unsigned int *" increases required alignment
from 1 to 4 [-Wcast-align]
Clang 3.1 warned that "attribute 'packed' is ignored". This stems from
placing "__attribute__ ((packed))" at the start of structure
declarations when common practice is to place it at the end.
Signed-off-by: Richard Yao <ryao@gentoo.org>
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Dave Reisner
Kay Sievers
Greg KH
Thomas Hindoe Paaboel Andersen
Karel Zak
Tom Gundersen
Lukas Nykryn
David Herrmann
Harald Hoyer
Michael Biebl
Jan Engelhardt
Hannes Reinecke
Richard Yao