Hi, On 01.02.2016, Linus Torvalds wrote: > Go forth and test, > > Linus Still, some Asus laptops are hanging at boot-time, both with latest -stable and 4.5-rc1/rc2: [ 4.056862] asus_laptop: model detected [ 4.058731] BUG: unable to handle kernel NULL pointer dereference at 0000000000000e20 [ 4.060018] IP: [<ffffffffc03d3423>] asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop] [ 4.061346] PGD 0 [ 4.062629] Oops: 0000 [#1] PREEMPT SMP [ 4.063960] Modules linked in: wmi asus_laptop(+) input_polldev sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc sch_fq_codel tcp_westwood xfs libcrc32c +hid_logitech_dj crc32c_intel serio_raw atl1c i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm i2c_core video [ 4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1 [ 4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS U45JC.208 02/24/2011 [ 4.070023] task: ffff88003645b680 ti: ffff8800a4a0c000 task.ti: ffff8800a4a0c000 [ 4.071568] RIP: 0010:[<ffffffffc03d3423>] [<ffffffffc03d3423>] asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop] [ 4.073188] RSP: 0000:ffff8800a4a0faf8 EFLAGS: 00010282 [ 4.074820] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 4.076462] RDX: 0000000000000000 RSI: ffffffffc03d63c0 RDI: ffff88003675b420 [ 4.078109] RBP: ffff8800a4a0fb08 R08: ffff8801428940c8 R09: 0000000000000124 [ 4.079777] R10: ffff88014348d100 R11: 0000000000000014 R12: ffffffffc03d4940 [ 4.081470] R13: 0000000000000000 R14: ffff8801418af000 R15: ffffffffc03d6220 [ 4.083156] FS: 00007f58ba6dd8c0(0000) GS:ffff880147c40000(0000) knlGS:0000000000000000 [ 4.084885] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.086611] CR2: 0000000000000e20 CR3: 00000000a49f3000 CR4: 00000000000006e0 [ 4.088351] Stack: [ 4.090066] 0000000000000000 ffffffffc03d4940 ffff8800a4a0fb50 ffffffff8122d12b [ 4.091838] 0000000000000000 ffff88003675b420 ffff880141327000 0000000000000000 [ 4.093606] 0000000000000000 ffff880036b42498 0000000000000001 ffff8800a4a0fb60 [ 4.095386] Call Trace: [ 4.097151] [<ffffffff8122d12b>] internal_create_group+0xbb/0x310 [ 4.098943] [<ffffffff8122d393>] sysfs_create_group+0x13/0x20 [ 4.100748] [<ffffffffc03d292b>] asus_acpi_add+0x3bb/0xea0 [asus_laptop] [ 4.102583] [<ffffffff81399d32>] acpi_device_probe+0x4f/0xf5 [ 4.104415] [<ffffffff81431107>] driver_probe_device+0x167/0x490 [ 4.106254] [<ffffffff814314b4>] __driver_attach+0x84/0x90 [ 4.108087] [<ffffffff81431430>] ? driver_probe_device+0x490/0x490 [ 4.109931] [<ffffffff8142ee34>] bus_for_each_dev+0x64/0xa0 [ 4.111724] [<ffffffff814309ae>] driver_attach+0x1e/0x20 [ 4.113509] [<ffffffff8143053b>] bus_add_driver+0x1eb/0x280 [ 4.115273] [<ffffffffc03da000>] ? 0xffffffffc03da000 [ 4.117032] [<ffffffff81431d10>] driver_register+0x60/0xe0 [ 4.118818] [<ffffffff81399c01>] acpi_bus_register_driver+0x38/0x40 [ 4.120619] [<ffffffffc03da02a>] asus_laptop_init+0x2a/0x1000 [asus_laptop] [ 4.122433] [<ffffffff810003db>] do_one_initcall+0xab/0x1c0 [ 4.124276] [<ffffffff8114b43e>] do_init_module+0x5f/0x1e5 [ 4.126114] [<ffffffff810d8dff>] load_module+0x1f3f/0x2530 [ 4.127943] [<ffffffff810d5500>] ? __symbol_put+0x50/0x50 [ 4.129786] [<ffffffff810d581b>] ? copy_module_from_fd.isra.50+0xdb/0x130 [ 4.131653] [<ffffffff810d95ea>] SyS_finit_module+0x9a/0xc0 [ 4.133521] [<ffffffff816bacd7>] entry_SYSCALL_64_fastpath+0x12/0x6a [ 4.135378] Code: c7 80 48 3d c0 e8 11 7e d7 c0 4c 89 f7 e8 66 3c e5 ff e9 27 ff ff ff 90 66 66 66 66 90 55 48 89 e5 41 54 53 48 8b 8790 00 00 00 <4c> 8b a0 20 0e 00 00 0f b6 80 95 0d 00 00 84 c0 74 1a 48 81 fe [ 4.139719] RIP [<ffffffffc03d3423>] asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop] [ 4.141788] RSP <ffff8800a4a0faf8> [ 4.143809] CR2: 0000000000000e20 [ 4.145867] ---[ end trace 7d8d7d572a3e9126 ]--- The bug is also reported here: https://bugzilla.kernel.org/show_bug.cgi?id=110751 This patch fixes the problem (both for me and others): From: Martin Wilck <Martin.Wilck@xxxxxxxxxxxxxx> Since b8b2c7d845d5, platform_drv_probe() is called for all platform devices. If drv->probe is NULL, and dev_pm_domain_attach() fails, platform_drv_probe() will return the error code from dev_pm_domain_attach(). This causes real_probe() to enter the "probe_failed" path and set dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume success if both dev->bus->probe and drv->probe were missing. As a result, a device and driver could be "bound" together just by matching their names; this doesn't work any more after b8b2c7d845d5. This change broke the assumptions of certain drivers; for example, the TPM code has long assumed that platform driver and device with matching name could be bound in this way. That assumption may cause such drivers to fail with Oops during initialization after applying this change. Failure in suspend/resume tests under qemu has also been reported. This patch restores the previous (4.3.0 and earlier) behavior of platform_drv_probe() in the case when the associated platform driver has no "probe" function. Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally") Signed-off-by: Martin Wilck <Martin.Wilck@xxxxxxxxxxxxxx> --- v2: fixed style issues, rephrased commit message. v3: rephrased commit message and subject again. drivers/base/platform.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 1dd6d3b..176b59f 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -513,10 +513,15 @@ static int platform_drv_probe(struct device *_dev) return ret; ret = dev_pm_domain_attach(_dev, true); - if (ret != -EPROBE_DEFER && drv->probe) { - ret = drv->probe(dev); - if (ret) - dev_pm_domain_detach(_dev, true); + if (ret != -EPROBE_DEFER) { + if (drv->probe) { + ret = drv->probe(dev); + if (ret) + dev_pm_domain_detach(_dev, true); + } else { + /* don't fail if just dev_pm_domain_attach failed */ + ret = 0; + } } if (drv->prevent_deferred_probe && ret == -EPROBE_DEFER) { -- 1.8.3.1 Thanks, Heinz -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html