When I tried to boot a system with 256 disks x 4 paths with
device-mapper, udevadm trigger (--type=devices) that was called
from start_udev ended up dumping a core due to a segmentation
fault.
In udev_enumerate_get_list_entry(), if it finds the devices that
should be delayed, it calls syspath_add(). If realloc() in
syspath_add() allocates the required memory at a different memory
address, referring prev->len afterward causes the segmentation
fault.
Signed-off-by: Kei Tokunaga <tokunaga.keiich@jp.fujitsu.com>
We need to preserve the database of network interfaces while we
rename them. Use the kernel's numbers wherever possible, instead
of the device names.
Fix wrong database filenames which contain a '/', translated
from '!' in the kernel name.
Fix segfault for kobject pathes where the subsystem can not be
determined from sysfs.
Renaming network devices might delay events for the other device, which has
the same devpath in the meantime as the original event. Causing a delay until
the timout of the event is reached.
Look at the ifindex/devnum of the devices to check if they are really
the same devices.
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>
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>
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>
Kay Sievers
Thomas Egerer
Kei Tokunaga
Yin Kangkai
Marco d'Itri
David Zeuthen
Scott James Remnant