aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBen Chan <benchan@chromium.org>2017-02-28 18:49:13 -0800
committerDan Williams <dcbw@redhat.com>2017-03-01 09:26:06 -0600
commit66b3367cf87e636f49f1e89c3f7645c7826d5eb2 (patch)
tree571a429f07d587c063b6c73ccefe3217a2a3fb99
parentbf27e44caf7c7868e139e58e510c307770074171 (diff)
kernel-device: handle SDIO device in find_physical_gudevdevice
A few crashes have been observed in the field with the following signature: Thread 0 CRASHED [SIGSEGV @ 0x00000000 ] MAGIC SIGNATURE THREAD 0xf53ff5e8 (libglib-2.0.so.0.3600.4 -ghash.c:1732 ) g_str_hash 0xf53fe8c7 (libglib-2.0.so.0.3600.4 -ghash.c:365 ) g_hash_table_lookup 0xb953c3bd (ModemManager -mm-base-manager.c:130 ) device_removed 0xb953cc9f (ModemManager -mm-base-manager.c:408 ) handle_uevent 0xf54c535f (libgobject-2.0.so.0.3600.4 -gclosure.c:777 ) g_closure_invoke 0xf54d6fc7 (libgobject-2.0.so.0.3600.4 -gsignal.c:3584 ) signal_emit_unlocked_R 0xf54d7baf (libgobject-2.0.so.0.3600.4 -gsignal.c:3328 ) g_signal_emit_valist 0xf54d7fa5 (libgobject-2.0.so.0.3600.4 -gsignal.c:3384 ) g_signal_emit 0xf5623819 (libgudev-1.0.so.0.2.0 -gudevclient.c:104 ) monitor_event 0xf540cc51 (libglib-2.0.so.0.3600.4 -gmain.c:3054 ) g_main_context_dispatch 0xf540cfa5 (libglib-2.0.so.0.3600.4 -gmain.c:3701 ) g_main_context_iterate 0xf540d2c5 (libglib-2.0.so.0.3600.4 -gmain.c:3895 ) g_main_loop_run 0xb9539dad (ModemManager -main.c:180 ) main 0xf52d687d (libc-2.23.so -libc-start.c:289 ) __libc_start_main 0xb9539bf3 (ModemManager + 0x0001cbf3 ) _start 0xb95b0fbf (ModemManager -elf-init.c:87 ) __libc_csu_init 0xf56dbe43 (ld-2.23.so + 0x0000be43 ) _dl_sort_fini 0xb9539bbf (ModemManager + 0x0001cbbf ) _init The crash happens when mm-kernel-device-udev.c:find_physical_gudevdevice() fails to find the physical device, which eventually leads to a NULL `physdev_uid' being passed to g_hash_table_lookup() in mm-base-manager.cc:find_device_by_physdev_uid(). There isn't much information about the actual device that triggered the udev event, but it's suspected to be a tty or net device on a SDIO bus and thus associated with a physical device on the 'sdio' subsystem. This patch updates find_physical_gudevdevice() in mm-kernel-device-udev.c to handle this particular scenario.
-rw-r--r--src/kerneldevice/mm-kernel-device-udev.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/src/kerneldevice/mm-kernel-device-udev.c b/src/kerneldevice/mm-kernel-device-udev.c
index 432832f4..763ccf86 100644
--- a/src/kerneldevice/mm-kernel-device-udev.c
+++ b/src/kerneldevice/mm-kernel-device-udev.c
@@ -178,7 +178,7 @@ find_physical_gudevdevice (GUdevDevice *child)
const char *subsys, *type, *name;
guint32 i = 0;
gboolean is_usb = FALSE, is_pci = FALSE, is_pcmcia = FALSE, is_platform = FALSE;
- gboolean is_pnp = FALSE;
+ gboolean is_pnp = FALSE, is_sdio = FALSE;
g_return_val_if_fail (child != NULL, NULL);
@@ -233,6 +233,10 @@ find_physical_gudevdevice (GUdevDevice *child)
is_pnp = TRUE;
physdev = iter;
break;
+ } else if (is_sdio || !strcmp (subsys, "sdio")) {
+ is_sdio = TRUE;
+ physdev = iter;
+ break;
}
}