Re: [PATCH] udevProcessCSS: fix segfault
On Mon, Sep 21, 2020 at 07:06:32PM +0200, Marc Hartmayer wrote:
Don't process subchannel devices where `def->driver` is not
set. This
fixes the following segfault:
Thread 21 "nodedev-init" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3ffb08fc910 (LWP 64303)]
(gdb) bt
#0 0x000003fffd1272b4 in __strcmp_vx () at /lib64/libc.so.6
#1 0x000003ffc260c3a8 in udevProcessCSS (device=0x3ff9018d130, def=0x3ff90194a90)
#2 0x000003ffc260cb78 in udevGetDeviceDetails (device=0x3ff9018d130,
def=0x3ff90194a90)
#3 0x000003ffc260d126 in udevAddOneDevice (device=0x3ff9018d130)
#4 0x000003ffc260d414 in udevProcessDeviceListEntry (udev=0x3ffa810d800,
list_entry=0x3ff90001990)
#5 0x000003ffc260d638 in udevEnumerateDevices (udev=0x3ffa810d800)
#6 0x000003ffc260e08e in nodeStateInitializeEnumerate (opaque=0x3ffa810d800)
#7 0x000003fffdaa14b6 in virThreadHelper (data=0x3ffa810df00)
#8 0x000003fffc309ed6 in start_thread ()
#9 0x000003fffd185e66 in thread_start ()
(gdb) p *def
$2 = {
name = 0x0,
sysfs_path = 0x3ff90198e80 "/sys/devices/css0/0.0.ff40",
Okay, this patch fixes the segfault. However, if ^this generated it because the
driver name is not set, how do we even get to the resulting device tree as
outlined in 05e6cdafa6e0?
+- css_0_0_003a
|
+- ccw_0_0_1a2b
|
+- scsi_host0
What kind of CSS device is the one causing the error? If we skip this CSS
device, we don't generate a name for it and don't put it in the list, so I'm
quite puzzled on what I missed in the IBM document and thus in the review
process.
FWIW:
Reviewed-by: Erik Skultety <eskultet(a)redhat.com>