* BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 @ 2010-12-14 9:40 Borislav Petkov 2010-12-14 20:29 ` Linus Torvalds 0 siblings, 1 reply; 4+ messages in thread From: Borislav Petkov @ 2010-12-14 9:40 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alex Deucher, x86, lkml The oops below happened today with v2.6.37-rc5-62-g6313e3c with the following hpet oneline fix which should be unrelated (tglx has an equivalent one in -tip/urgent already): diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index ae03cab..0388a70 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -408,7 +408,7 @@ static int hpet_next_event(unsigned long delta, */ res = (s32)(cnt - hpet_readl(HPET_COUNTER)); - return res < 8 ? -ETIME : 0; + return res < 128 ? -ETIME : 0; } static void hpet_legacy_set_mode(enum clock_event_mode mode, -- SysRq was still functioning though and I was able to sync+reboot therefore the oops is from /var/log/syslog. Any ideas? -- Dec 14 10:17:26 liondog kernel: [12312.144385] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 Dec 14 10:17:26 liondog kernel: [12312.144390] in_atomic(): 0, irqs_disabled(): 1, pid: 1930, name: Xorg Dec 14 10:17:26 liondog kernel: [12312.144393] no locks held by Xorg/1930. Dec 14 10:17:26 liondog kernel: [12312.144394] irq event stamp: 959429057 Dec 14 10:17:26 liondog kernel: [12312.144396] hardirqs last enabled at (959429057): [<ffffffff81021d4e>] do_page_fault+0xa5/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144402] hardirqs last disabled at (959429056): [<ffffffff8144f403>] error_sti+0x5/0x6 Dec 14 10:17:26 liondog kernel: [12312.144407] softirqs last enabled at (959429046): [<ffffffff81041f38>] __do_softirq+0x2b4/0x304 Dec 14 10:17:26 liondog kernel: [12312.144412] softirqs last disabled at (959429021): [<ffffffff8100324c>] call_softirq+0x1c/0x28 Dec 14 10:17:26 liondog kernel: [12312.144417] Pid: 1930, comm: Xorg Not tainted 2.6.37-rc5-00063-g779049f #1 Dec 14 10:17:26 liondog kernel: [12312.144419] Call Trace: Dec 14 10:17:26 liondog kernel: [12312.144424] [<ffffffff81068dc0>] ? print_irqtrace_events+0xd0/0xd4 Dec 14 10:17:26 liondog kernel: [12312.144429] [<ffffffff81030cc8>] __might_sleep+0x11c/0x120 Dec 14 10:17:26 liondog kernel: [12312.144432] [<ffffffff81021e69>] do_page_fault+0x1c0/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144436] [<ffffffff8144b861>] ? schedule+0xafa/0xb85 Dec 14 10:17:26 liondog kernel: [12312.144438] [<ffffffff8144f403>] ? error_sti+0x5/0x6 Dec 14 10:17:26 liondog kernel: [12312.144441] [<ffffffff81069fa2>] ? trace_hardirqs_off_caller+0x1f/0x10e Dec 14 10:17:26 liondog kernel: [12312.144444] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c Dec 14 10:17:26 liondog kernel: [12312.144448] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.144451] [<ffffffff8144f21f>] page_fault+0x1f/0x30 Dec 14 10:17:26 liondog kernel: [12312.144454] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.144457] [<ffffffff8106d1da>] ? __lock_acquire+0x19d/0x173f Dec 14 10:17:26 liondog kernel: [12312.144460] [<ffffffff81069d4a>] ? put_lock_stats+0xe/0x29 Dec 14 10:17:26 liondog kernel: [12312.144464] [<ffffffff8144c1ea>] ? __mutex_unlock_slowpath+0x105/0x129 Dec 14 10:17:26 liondog kernel: [12312.144467] [<ffffffff8106b29d>] ? trace_hardirqs_on+0xd/0xf Dec 14 10:17:26 liondog kernel: [12312.144469] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144472] [<ffffffff8106e8c9>] lock_acquire+0x14d/0x192 Dec 14 10:17:26 liondog kernel: [12312.144475] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144477] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.144481] [<ffffffff8105ea37>] down_read_trylock+0x56/0x5f Dec 14 10:17:26 liondog kernel: [12312.144484] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144486] [<ffffffff81021e19>] do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144490] [<ffffffff810f6159>] ? do_vfs_ioctl+0x4d0/0x51f Dec 14 10:17:26 liondog kernel: [12312.144493] [<ffffffff8144f403>] ? error_sti+0x5/0x6 Dec 14 10:17:26 liondog kernel: [12312.144495] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c Dec 14 10:17:26 liondog kernel: [12312.144498] [<ffffffff8144f21f>] page_fault+0x1f/0x30 Dec 14 10:17:26 liondog kernel: [12312.144509] BUG: unable to handle kernel paging request at 00000110850fc085 Dec 14 10:17:26 liondog kernel: [12312.144512] IP: [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f Dec 14 10:17:26 liondog kernel: [12312.144516] PGD 0 Dec 14 10:17:26 liondog kernel: [12312.144518] Oops: 0000 [#1] PREEMPT SMP Dec 14 10:17:26 liondog kernel: [12312.144521] last sysfs file: /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq Dec 14 10:17:26 liondog kernel: [12312.144524] CPU 1 Dec 14 10:17:26 liondog kernel: [12312.144526] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables powernow_k8 mperf cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats freq_table binfmt_misc kvm_amd kvm fuse ipv6 vfat fat 8250_pnp 8250 serial_core ohci_hcd edac_core k10temp Dec 14 10:17:26 liondog kernel: [12312.144548] Dec 14 10:17:26 liondog kernel: [12312.144551] Pid: 1930, comm: Xorg Not tainted 2.6.37-rc5-00063-g779049f #1 M3A78 PRO/System Product Name Dec 14 10:17:26 liondog kernel: [12312.144553] RIP: 0010:[<ffffffff8106d1da>] [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f Dec 14 10:17:26 liondog kernel: [12312.144557] RSP: 0000:ffff88022d1b3cb8 EFLAGS: 00013087 Dec 14 10:17:26 liondog kernel: [12312.144559] RAX: ffffffff819bb000 RBX: ffff88022d09da00 RCX: ffffffff821c6b40 Dec 14 10:17:26 liondog kernel: [12312.144561] RDX: 00000110850fc085 RSI: 0000000000000000 RDI: 8000000000000000 Dec 14 10:17:26 liondog kernel: [12312.144563] RBP: ffff88022d1b3d88 R08: 0000000000000002 R09: 0000000000000000 Dec 14 10:17:26 liondog kernel: [12312.144564] R10: ffffffff8124f16c R11: 0000000000001128 R12: ffff88022f445b90 Dec 14 10:17:26 liondog kernel: [12312.144566] R13: 0000000000000000 R14: 00000110850fc085 R15: 0000000000000002 Dec 14 10:17:26 liondog kernel: [12312.144569] FS: 00007f2fe2941700(0000) GS:ffff8800cf000000(0000) knlGS:00000000f6a4c740 Dec 14 10:17:26 liondog kernel: [12312.144571] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Dec 14 10:17:26 liondog kernel: [12312.144572] CR2: 00000110850fc085 CR3: 000000022b965000 CR4: 00000000000006e0 Dec 14 10:17:26 liondog kernel: [12312.144574] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Dec 14 10:17:26 liondog kernel: [12312.144576] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Dec 14 10:17:26 liondog kernel: [12312.144578] Process Xorg (pid: 1930, threadinfo ffff88022d1b2000, task ffff88022f445b90) Dec 14 10:17:26 liondog kernel: [12312.144580] Stack: Dec 14 10:17:26 liondog kernel: [12312.144581] 0000000000000046 0000000000000001 ffff88022d1b3ce8 0000000081032b75 Dec 14 10:17:26 liondog kernel: [12312.144585] ffff880200000001 0000000000000001 ffff88022d1b3cf8 ffffffff81069d4a Dec 14 10:17:26 liondog kernel: [12312.144589] ffff88022d1b3d18 ffff88022f445b90 ffff88022f445b90 ffffffff8144c1ea Dec 14 10:17:26 liondog kernel: [12312.144593] Call Trace: Dec 14 10:17:26 liondog kernel: [12312.144596] [<ffffffff81069d4a>] ? put_lock_stats+0xe/0x29 Dec 14 10:17:26 liondog kernel: [12312.144599] [<ffffffff8144c1ea>] ? __mutex_unlock_slowpath+0x105/0x129 Dec 14 10:17:26 liondog kernel: [12312.144602] [<ffffffff8106b29d>] ? trace_hardirqs_on+0xd/0xf Dec 14 10:17:26 liondog kernel: [12312.144605] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144608] [<ffffffff8106e8c9>] lock_acquire+0x14d/0x192 Dec 14 10:17:26 liondog kernel: [12312.144610] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144613] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.144616] [<ffffffff8105ea37>] down_read_trylock+0x56/0x5f Dec 14 10:17:26 liondog kernel: [12312.144619] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144621] [<ffffffff81021e19>] do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.144624] [<ffffffff810f6159>] ? do_vfs_ioctl+0x4d0/0x51f Dec 14 10:17:26 liondog kernel: [12312.144627] [<ffffffff8144f403>] ? error_sti+0x5/0x6 Dec 14 10:17:26 liondog kernel: [12312.144630] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c Dec 14 10:17:26 liondog kernel: [12312.144632] [<ffffffff8144f21f>] page_fault+0x1f/0x30 Dec 14 10:17:26 liondog kernel: [12312.144634] Code: 01 00 00 74 33 80 3d 25 1b c7 00 01 74 2a be a6 02 00 00 48 c7 c7 d1 8b 5e 81 e8 af dc fc ff c6 05 0b 1b c7 00 01 eb 10 49 89 d6 <49> 8b 16 49 39 ce 0f 18 0a 75 bc eb 09 4d 85 f6 0f 85 2e 03 00 Dec 14 10:17:26 liondog kernel: [12312.144671] RIP [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f Dec 14 10:17:26 liondog kernel: [12312.144674] RSP <ffff88022d1b3cb8> Dec 14 10:17:26 liondog kernel: [12312.144676] CR2: 00000110850fc085 Dec 14 10:17:26 liondog kernel: [12312.144678] ---[ end trace b215ad3559f4bac0 ]--- Dec 14 10:17:26 liondog kernel: [12312.218747] general protection fault: 0000 [#2] PREEMPT SMP Dec 14 10:17:26 liondog kernel: [12312.218754] last sysfs file: /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq Dec 14 10:17:26 liondog kernel: [12312.218757] CPU 1 Dec 14 10:17:26 liondog kernel: [12312.218758] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables powernow_k8 mperf cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats freq_table binfmt_misc kvm_amd kvm fuse ipv6 vfat fat 8250_pnp 8250 serial_core ohci_hcd edac_core k10temp Dec 14 10:17:26 liondog kernel: [12312.218783] Dec 14 10:17:26 liondog kernel: [12312.218787] Pid: 1930, comm: Xorg Tainted: G D 2.6.37-rc5-00063-g779049f #1 M3A78 PRO/System Product Name Dec 14 10:17:26 liondog kernel: [12312.218789] RIP: 0010:[<ffffffff8124bee0>] [<ffffffff8124bee0>] radeon_read_ring_rptr+0x30/0x34 Dec 14 10:17:26 liondog kernel: [12312.218797] RSP: 0000:ffff88022d1b3730 EFLAGS: 00013202 Dec 14 10:17:26 liondog kernel: [12312.218799] RAX: ffff88022a8e55d8 RBX: ffff88022fc252d0 RCX: ffffc90011380000 Dec 14 10:17:26 liondog kernel: [12312.218801] RDX: 000000000000002c RSI: 6b6b6b6b6b6b6b6b RDI: ffff88022fc252d0 Dec 14 10:17:26 liondog kernel: [12312.218804] RBP: ffff88022d1b3730 R08: ffffffff81231039 R09: ffffea00079555a0 Dec 14 10:17:26 liondog kernel: [12312.218806] R10: ffff88022d1b3778 R11: ffff88022d1b37a8 R12: 0000000000000010 Dec 14 10:17:26 liondog kernel: [12312.218807] R13: ffff88022fc2b0d8 R14: ffff88022fc25450 R15: ffff88022fc2b2e0 Dec 14 10:17:26 liondog kernel: [12312.218810] FS: 00007f2fe2941700(0000) GS:ffff8800cf000000(0000) knlGS:00000000f6a4c740 Dec 14 10:17:26 liondog kernel: [12312.218812] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Dec 14 10:17:26 liondog kernel: [12312.218814] CR2: 00000110850fc085 CR3: 00000000016a1000 CR4: 00000000000006e0 Dec 14 10:17:26 liondog kernel: [12312.218816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Dec 14 10:17:26 liondog kernel: [12312.218818] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Dec 14 10:17:26 liondog kernel: [12312.218820] Process Xorg (pid: 1930, threadinfo ffff88022d1b2000, task ffff88022f445b90) Dec 14 10:17:26 liondog kernel: [12312.218821] Stack: Dec 14 10:17:26 liondog kernel: [12312.218823] ffff88022d1b3740 ffffffff8124befa ffff88022d1b3758 ffffffff8124c625 Dec 14 10:17:26 liondog kernel: [12312.218827] ffff88022fc252d0 ffff88022d1b3778 ffffffff8125e6f6 ffff88022fc252d0 Dec 14 10:17:26 liondog kernel: [12312.218832] ffff88022fc2b0d8 ffff88022d1b3798 ffffffff8124f5b4 ffff88022fc25450 Dec 14 10:17:26 liondog kernel: [12312.218835] Call Trace: Dec 14 10:17:26 liondog kernel: [12312.218840] [<ffffffff8124befa>] radeon_get_ring_head+0x16/0x41 Dec 14 10:17:26 liondog kernel: [12312.218843] [<ffffffff8124c625>] radeon_commit_ring+0x4d/0x9c Dec 14 10:17:26 liondog kernel: [12312.218847] [<ffffffff8125e6f6>] r600_do_cp_idle+0xf5/0x102 Dec 14 10:17:26 liondog kernel: [12312.218850] [<ffffffff8124f5b4>] radeon_do_release+0x63/0x1ad Dec 14 10:17:26 liondog kernel: [12312.218853] [<ffffffff81259217>] radeon_driver_lastclose+0x52/0x5b Dec 14 10:17:26 liondog kernel: [12312.218857] [<ffffffff812306a3>] drm_lastclose+0x4f/0x28c Dec 14 10:17:26 liondog kernel: [12312.218860] [<ffffffff81231088>] drm_release+0x59d/0x5d8 Dec 14 10:17:26 liondog kernel: [12312.218865] [<ffffffff810e859a>] fput+0x126/0x1e6 Dec 14 10:17:26 liondog kernel: [12312.218868] [<ffffffff810e50e7>] filp_close+0x5d/0x67 Dec 14 10:17:26 liondog kernel: [12312.218873] [<ffffffff8103ce8f>] put_files_struct+0x12d/0x254 Dec 14 10:17:26 liondog kernel: [12312.218876] [<ffffffff8103cd89>] ? put_files_struct+0x27/0x254 Dec 14 10:17:26 liondog kernel: [12312.218880] [<ffffffff81032b75>] ? sub_preempt_count+0xa3/0xb7 Dec 14 10:17:26 liondog kernel: [12312.218883] [<ffffffff8103d001>] exit_files+0x4b/0x53 Dec 14 10:17:26 liondog kernel: [12312.218886] [<ffffffff8103eb49>] do_exit+0x296/0x765 Dec 14 10:17:26 liondog kernel: [12312.218889] [<ffffffff8103bd07>] ? kmsg_dump+0x13b/0x155 Dec 14 10:17:26 liondog kernel: [12312.218892] [<ffffffff81006286>] oops_end+0x8e/0x93 Dec 14 10:17:26 liondog kernel: [12312.218896] [<ffffffff8102195a>] no_context+0x1fc/0x20b Dec 14 10:17:26 liondog kernel: [12312.218898] [<ffffffff81021afe>] __bad_area_nosemaphore+0x195/0x1b8 Dec 14 10:17:26 liondog kernel: [12312.218901] [<ffffffff81021b7d>] bad_area+0x47/0x4e Dec 14 10:17:26 liondog kernel: [12312.218904] [<ffffffff81021ec0>] do_page_fault+0x217/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.218908] [<ffffffff8144b861>] ? schedule+0xafa/0xb85 Dec 14 10:17:26 liondog kernel: [12312.218911] [<ffffffff8144f403>] ? error_sti+0x5/0x6 Dec 14 10:17:26 liondog kernel: [12312.218915] [<ffffffff81069fa2>] ? trace_hardirqs_off_caller+0x1f/0x10e Dec 14 10:17:26 liondog kernel: [12312.218918] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c Dec 14 10:17:26 liondog kernel: [12312.218921] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.218923] [<ffffffff8144f21f>] page_fault+0x1f/0x30 Dec 14 10:17:26 liondog kernel: [12312.218926] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.218930] [<ffffffff8106d1da>] ? __lock_acquire+0x19d/0x173f Dec 14 10:17:26 liondog kernel: [12312.218933] [<ffffffff81069d4a>] ? put_lock_stats+0xe/0x29 Dec 14 10:17:26 liondog kernel: [12312.218936] [<ffffffff8144c1ea>] ? __mutex_unlock_slowpath+0x105/0x129 Dec 14 10:17:26 liondog kernel: [12312.218939] [<ffffffff8106b29d>] ? trace_hardirqs_on+0xd/0xf Dec 14 10:17:26 liondog kernel: [12312.218942] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.218945] [<ffffffff8106e8c9>] lock_acquire+0x14d/0x192 Dec 14 10:17:26 liondog kernel: [12312.218947] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.218950] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 Dec 14 10:17:26 liondog kernel: [12312.218954] [<ffffffff8105ea37>] down_read_trylock+0x56/0x5f Dec 14 10:17:26 liondog kernel: [12312.218957] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.218960] [<ffffffff81021e19>] do_page_fault+0x170/0x3a7 Dec 14 10:17:26 liondog kernel: [12312.218964] [<ffffffff810f6159>] ? do_vfs_ioctl+0x4d0/0x51f Dec 14 10:17:26 liondog kernel: [12312.218967] [<ffffffff8144f403>] ? error_sti+0x5/0x6 Dec 14 10:17:26 liondog kernel: [12312.218969] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c Dec 14 10:17:26 liondog kernel: [12312.218973] [<ffffffff8144f21f>] page_fault+0x1f/0x30 Dec 14 10:17:26 liondog kernel: [12312.218975] Code: 66 66 66 90 f6 87 1a 04 00 00 08 48 8b 87 10 01 00 00 74 0a 89 f6 48 03 70 18 8b 06 eb 0f c1 ee 02 89 f6 48 c1 e6 02 48 03 70 18 <8b> 06 c9 c3 55 48 89 e5 66 66 66 66 90 83 7f 74 00 74 09 31 f6 Dec 14 10:17:26 liondog kernel: [12312.219015] RIP [<ffffffff8124bee0>] radeon_read_ring_rptr+0x30/0x34 Dec 14 10:17:26 liondog kernel: [12312.219018] RSP <ffff88022d1b3730> Dec 14 10:17:26 liondog kernel: [12312.219037] ---[ end trace b215ad3559f4bac1 ]--- Dec 14 10:17:26 liondog kernel: [12312.219039] Fixing recursive fault but reboot is needed! Dec 14 10:18:27 liondog kernel: [12372.372053] SysRq : HELP : loglevel(0-9) reBoot Crash show-all-locks(D) terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z) Dec 14 10:18:27 liondog kernel: [12373.142367] SysRq : Emergency Sync Dec 14 10:18:27 liondog kernel: [12373.158134] Emergency Sync complete Dec 14 10:18:29 liondog kernel: [12374.271069] SysRq : Emergency Remount R/O -- Regards/Gruss, Boris. ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 2010-12-14 9:40 BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 Borislav Petkov @ 2010-12-14 20:29 ` Linus Torvalds 2010-12-14 22:42 ` Borislav Petkov 2010-12-15 9:52 ` Peter Zijlstra 0 siblings, 2 replies; 4+ messages in thread From: Linus Torvalds @ 2010-12-14 20:29 UTC (permalink / raw) To: Borislav Petkov, Alex Deucher, x86, lkml, Peter Zijlstra, Ingo Molnar On Tue, Dec 14, 2010 at 1:40 AM, Borislav Petkov <bp@alien8.de> wrote: > > The oops below happened today with v2.6.37-rc5-62-g6313e3c with the > following hpet oneline fix which should be unrelated (tglx has an > equivalent one in -tip/urgent already): The "sleeping function called from invalid context" part is uninteresting - it's just a result of the real bug, which is the oops. The oops gets printed out later, because the might_sleep() test just happens to trigger first in the page faulting path. So ignore the early part of the dmesg, the only thing relevant is the kernel paging request in __lock_acquire. Of course, that one is then followed rather closely by a GP fault in the radeon driver, which I don't know is real or not. It could easily be some bad interaction with the kmsg_dump() thing (a result of the first page fault) interacting badly with the X server getting killed by that bogus page fault. So it's hard to tell whether the GP fault is real and maybe relevant for the discussion, or whether it's a result of the earlier oops. > Dec 14 10:17:26 liondog kernel: [12312.144509] BUG: unable to handle kernel paging request at 00000110850fc085 > Dec 14 10:17:26 liondog kernel: [12312.144512] IP: [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f > Dec 14 10:17:26 liondog kernel: [12312.144516] PGD 0 > Dec 14 10:17:26 liondog kernel: [12312.144518] Oops: 0000 [#1] PREEMPT SMP > Dec 14 10:17:26 liondog kernel: [12312.144521] last sysfs file: /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq > Dec 14 10:17:26 liondog kernel: [12312.144524] CPU 1 > Dec 14 10:17:26 liondog kernel: [12312.144526] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables powernow_k8 mperf cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats freq_table binfmt_misc kvm_amd kvm fuse ipv6 vfat fat 8250_pnp 8250 serial_core ohci_hcd edac_core k10temp > Dec 14 10:17:26 liondog kernel: [12312.144548] > Dec 14 10:17:26 liondog kernel: [12312.144551] Pid: 1930, comm: Xorg Not tainted 2.6.37-rc5-00063-g779049f #1 M3A78 PRO/System Product Name > Dec 14 10:17:26 liondog kernel: [12312.144553] RIP: 0010:[<ffffffff8106d1da>] [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f > Dec 14 10:17:26 liondog kernel: [12312.144557] RSP: 0000:ffff88022d1b3cb8 EFLAGS: 00013087 > Dec 14 10:17:26 liondog kernel: [12312.144559] RAX: ffffffff819bb000 RBX: ffff88022d09da00 RCX: ffffffff821c6b40 > Dec 14 10:17:26 liondog kernel: [12312.144561] RDX: 00000110850fc085 RSI: 0000000000000000 RDI: 8000000000000000 > Dec 14 10:17:26 liondog kernel: [12312.144563] RBP: ffff88022d1b3d88 R08: 0000000000000002 R09: 0000000000000000 > Dec 14 10:17:26 liondog kernel: [12312.144564] R10: ffffffff8124f16c R11: 0000000000001128 R12: ffff88022f445b90 > Dec 14 10:17:26 liondog kernel: [12312.144566] R13: 0000000000000000 R14: 00000110850fc085 R15: 0000000000000002 > Dec 14 10:17:26 liondog kernel: [12312.144569] FS: 00007f2fe2941700(0000) GS:ffff8800cf000000(0000) knlGS:00000000f6a4c740 > Dec 14 10:17:26 liondog kernel: [12312.144571] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > Dec 14 10:17:26 liondog kernel: [12312.144572] CR2: 00000110850fc085 CR3: 000000022b965000 CR4: 00000000000006e0 > Dec 14 10:17:26 liondog kernel: [12312.144574] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > Dec 14 10:17:26 liondog kernel: [12312.144576] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Dec 14 10:17:26 liondog kernel: [12312.144578] Process Xorg (pid: 1930, threadinfo ffff88022d1b2000, task ffff88022f445b90) > Dec 14 10:17:26 liondog kernel: [12312.144580] Stack: > Dec 14 10:17:26 liondog kernel: [12312.144581] 0000000000000046 0000000000000001 ffff88022d1b3ce8 0000000081032b75 > Dec 14 10:17:26 liondog kernel: [12312.144585] ffff880200000001 0000000000000001 ffff88022d1b3cf8 ffffffff81069d4a > Dec 14 10:17:26 liondog kernel: [12312.144589] ffff88022d1b3d18 ffff88022f445b90 ffff88022f445b90 ffffffff8144c1ea > Dec 14 10:17:26 liondog kernel: [12312.144593] Call Trace: > Dec 14 10:17:26 liondog kernel: [12312.144596] [<ffffffff81069d4a>] ? put_lock_stats+0xe/0x29 > Dec 14 10:17:26 liondog kernel: [12312.144599] [<ffffffff8144c1ea>] ? __mutex_unlock_slowpath+0x105/0x129 > Dec 14 10:17:26 liondog kernel: [12312.144602] [<ffffffff8106b29d>] ? trace_hardirqs_on+0xd/0xf > Dec 14 10:17:26 liondog kernel: [12312.144605] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 > Dec 14 10:17:26 liondog kernel: [12312.144608] [<ffffffff8106e8c9>] lock_acquire+0x14d/0x192 > Dec 14 10:17:26 liondog kernel: [12312.144610] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 > Dec 14 10:17:26 liondog kernel: [12312.144613] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 > Dec 14 10:17:26 liondog kernel: [12312.144616] [<ffffffff8105ea37>] down_read_trylock+0x56/0x5f > Dec 14 10:17:26 liondog kernel: [12312.144619] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 > Dec 14 10:17:26 liondog kernel: [12312.144621] [<ffffffff81021e19>] do_page_fault+0x170/0x3a7 > Dec 14 10:17:26 liondog kernel: [12312.144624] [<ffffffff810f6159>] ? do_vfs_ioctl+0x4d0/0x51f > Dec 14 10:17:26 liondog kernel: [12312.144627] [<ffffffff8144f403>] ? error_sti+0x5/0x6 > Dec 14 10:17:26 liondog kernel: [12312.144630] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c > Dec 14 10:17:26 liondog kernel: [12312.144632] [<ffffffff8144f21f>] page_fault+0x1f/0x30 > Dec 14 10:17:26 liondog kernel: [12312.144634] Code: 01 00 00 74 33 80 3d 25 1b c7 00 01 74 2a be a6 02 00 00 48 c7 c7 d1 8b 5e 81 e8 af dc fc ff c6 05 0b 1b c7 00 01 eb 10 49 89 d6 <49> 8b 16 49 39 ce 0f 18 0a 75 bc eb 09 4d 85 f6 0f 85 2e 03 00 > Dec 14 10:17:26 liondog kernel: [12312.144671] RIP [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f > Dec 14 10:17:26 liondog kernel: [12312.144674] RSP <ffff88022d1b3cb8> > Dec 14 10:17:26 liondog kernel: [12312.144676] CR2: 00000110850fc085 > Dec 14 10:17:26 liondog kernel: [12312.144678] ---[ end trace b215ad3559f4bac0 ]--- That code disassembles to 0: 74 33 je 0x35 2: 80 3d 25 1b c7 00 01 cmpb $0x1,0xc71b25(%rip) # 0xc71b2e 9: 74 2a je 0x35 b: be a6 02 00 00 mov $0x2a6,%esi 10: 48 c7 c7 d1 8b 5e 81 mov $0xffffffff815e8bd1,%rdi 17: e8 af dc fc ff callq 0xfffffffffffcdccb 1c: c6 05 0b 1b c7 00 01 movb $0x1,0xc71b0b(%rip) # 0xc71b2e 23: eb 10 jmp 0x35 25: 49 89 d6 mov %rdx,%r14 28:* 49 8b 16 mov (%r14),%rdx <-- trapping instruction 2b: 49 39 ce cmp %rcx,%r14 2e: 0f 18 0a prefetcht0 (%rdx) 31: 75 bc jne 0xffffffffffffffef 33: eb 09 jmp 0x3e which I think matches up with this: movq (%rdx), %rsi # class_293->hash_entry.next, D.31652 cmpq %rcx, %rdx # hash_head, class prefetcht0 (%rsi) # D.31652 jne .L449 #, jmp .L560 # which looks like one of the "list_for_each_entry()" uses of that hash_head. In fact, building lockdep.lst and matching against that 0x2a6 constant (it's a warn_slowpath_null thing and is the line number), we can pinpoint exactly which one it seems to be. Afaik, it seems to be this code in look_up_lock_class: /* * We can walk the hash lockfree, because the hash only * grows, and we are careful when adding entries to the end: */ list_for_each_entry(class, hash_head, hash_entry) { if (class->key == key) { WARN_ON_ONCE(class->name != lock->name); return class; } } Maybe the RCU list use in lockdep isn't entirely safe? Added Peter and Ingo to the cc. It does look like some lockdep race. Or then it's some general memory corruption, of course. That just happened to hit the lockdep data structures. That would explain your subsequent radeon GP fault too. Linus ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 2010-12-14 20:29 ` Linus Torvalds @ 2010-12-14 22:42 ` Borislav Petkov 2010-12-15 9:52 ` Peter Zijlstra 1 sibling, 0 replies; 4+ messages in thread From: Borislav Petkov @ 2010-12-14 22:42 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alex Deucher, x86, lkml, Peter Zijlstra, Ingo Molnar On Tue, Dec 14, 2010 at 12:29:52PM -0800, Linus Torvalds wrote: > On Tue, Dec 14, 2010 at 1:40 AM, Borislav Petkov <bp@alien8.de> wrote: > > > > The oops below happened today with v2.6.37-rc5-62-g6313e3c with the > > following hpet oneline fix which should be unrelated (tglx has an > > equivalent one in -tip/urgent already): > > The "sleeping function called from invalid context" part is > uninteresting - it's just a result of the real bug, which is the oops. > The oops gets printed out later, because the might_sleep() test just > happens to trigger first in the page faulting path. > > So ignore the early part of the dmesg, the only thing relevant is the > kernel paging request in __lock_acquire. Hm, that's something I wouldn't have seen from this perspective - I would've started chasing the reason for triggering the might_sleep() check... > Of course, that one is then followed rather closely by a GP fault in > the radeon driver, which I don't know is real or not. It could easily > be some bad interaction with the kmsg_dump() thing (a result of the > first page fault) interacting badly with the X server getting killed > by that bogus page fault. So it's hard to tell whether the GP fault is > real and maybe relevant for the discussion, or whether it's a result > of the earlier oops. I think so too, the GP is most probably a result of the PF. > > > Dec 14 10:17:26 liondog kernel: [12312.144509] BUG: unable to handle kernel paging request at 00000110850fc085 > > Dec 14 10:17:26 liondog kernel: [12312.144512] IP: [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f > > Dec 14 10:17:26 liondog kernel: [12312.144516] PGD 0 > > Dec 14 10:17:26 liondog kernel: [12312.144518] Oops: 0000 [#1] PREEMPT SMP > > Dec 14 10:17:26 liondog kernel: [12312.144521] last sysfs file: /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq > > Dec 14 10:17:26 liondog kernel: [12312.144524] CPU 1 > > Dec 14 10:17:26 liondog kernel: [12312.144526] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables powernow_k8 mperf cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats freq_table binfmt_misc kvm_amd kvm fuse ipv6 vfat fat 8250_pnp 8250 serial_core ohci_hcd edac_core k10temp > > Dec 14 10:17:26 liondog kernel: [12312.144548] > > Dec 14 10:17:26 liondog kernel: [12312.144551] Pid: 1930, comm: Xorg Not tainted 2.6.37-rc5-00063-g779049f #1 M3A78 PRO/System Product Name > > Dec 14 10:17:26 liondog kernel: [12312.144553] RIP: 0010:[<ffffffff8106d1da>] [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f > > Dec 14 10:17:26 liondog kernel: [12312.144557] RSP: 0000:ffff88022d1b3cb8 EFLAGS: 00013087 > > Dec 14 10:17:26 liondog kernel: [12312.144559] RAX: ffffffff819bb000 RBX: ffff88022d09da00 RCX: ffffffff821c6b40 > > Dec 14 10:17:26 liondog kernel: [12312.144561] RDX: 00000110850fc085 RSI: 0000000000000000 RDI: 8000000000000000 > > Dec 14 10:17:26 liondog kernel: [12312.144563] RBP: ffff88022d1b3d88 R08: 0000000000000002 R09: 0000000000000000 > > Dec 14 10:17:26 liondog kernel: [12312.144564] R10: ffffffff8124f16c R11: 0000000000001128 R12: ffff88022f445b90 > > Dec 14 10:17:26 liondog kernel: [12312.144566] R13: 0000000000000000 R14: 00000110850fc085 R15: 0000000000000002 > > Dec 14 10:17:26 liondog kernel: [12312.144569] FS: 00007f2fe2941700(0000) GS:ffff8800cf000000(0000) knlGS:00000000f6a4c740 > > Dec 14 10:17:26 liondog kernel: [12312.144571] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > Dec 14 10:17:26 liondog kernel: [12312.144572] CR2: 00000110850fc085 CR3: 000000022b965000 CR4: 00000000000006e0 > > Dec 14 10:17:26 liondog kernel: [12312.144574] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > Dec 14 10:17:26 liondog kernel: [12312.144576] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > Dec 14 10:17:26 liondog kernel: [12312.144578] Process Xorg (pid: 1930, threadinfo ffff88022d1b2000, task ffff88022f445b90) > > Dec 14 10:17:26 liondog kernel: [12312.144580] Stack: > > Dec 14 10:17:26 liondog kernel: [12312.144581] 0000000000000046 0000000000000001 ffff88022d1b3ce8 0000000081032b75 > > Dec 14 10:17:26 liondog kernel: [12312.144585] ffff880200000001 0000000000000001 ffff88022d1b3cf8 ffffffff81069d4a > > Dec 14 10:17:26 liondog kernel: [12312.144589] ffff88022d1b3d18 ffff88022f445b90 ffff88022f445b90 ffffffff8144c1ea > > Dec 14 10:17:26 liondog kernel: [12312.144593] Call Trace: > > Dec 14 10:17:26 liondog kernel: [12312.144596] [<ffffffff81069d4a>] ? put_lock_stats+0xe/0x29 > > Dec 14 10:17:26 liondog kernel: [12312.144599] [<ffffffff8144c1ea>] ? __mutex_unlock_slowpath+0x105/0x129 > > Dec 14 10:17:26 liondog kernel: [12312.144602] [<ffffffff8106b29d>] ? trace_hardirqs_on+0xd/0xf > > Dec 14 10:17:26 liondog kernel: [12312.144605] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 > > Dec 14 10:17:26 liondog kernel: [12312.144608] [<ffffffff8106e8c9>] lock_acquire+0x14d/0x192 > > Dec 14 10:17:26 liondog kernel: [12312.144610] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 > > Dec 14 10:17:26 liondog kernel: [12312.144613] [<ffffffff8124f16c>] ? radeon_cp_idle+0x0/0xa6 > > Dec 14 10:17:26 liondog kernel: [12312.144616] [<ffffffff8105ea37>] down_read_trylock+0x56/0x5f > > Dec 14 10:17:26 liondog kernel: [12312.144619] [<ffffffff81021e19>] ? do_page_fault+0x170/0x3a7 > > Dec 14 10:17:26 liondog kernel: [12312.144621] [<ffffffff81021e19>] do_page_fault+0x170/0x3a7 > > Dec 14 10:17:26 liondog kernel: [12312.144624] [<ffffffff810f6159>] ? do_vfs_ioctl+0x4d0/0x51f > > Dec 14 10:17:26 liondog kernel: [12312.144627] [<ffffffff8144f403>] ? error_sti+0x5/0x6 > > Dec 14 10:17:26 liondog kernel: [12312.144630] [<ffffffff8144dbfb>] ? trace_hardirqs_off_thunk+0x3a/0x3c > > Dec 14 10:17:26 liondog kernel: [12312.144632] [<ffffffff8144f21f>] page_fault+0x1f/0x30 > > Dec 14 10:17:26 liondog kernel: [12312.144634] Code: 01 00 00 74 33 80 3d 25 1b c7 00 01 74 2a be a6 02 00 00 48 c7 c7 d1 8b 5e 81 e8 af dc fc ff c6 05 0b 1b c7 00 01 eb 10 49 89 d6 <49> 8b 16 49 39 ce 0f 18 0a 75 bc eb 09 4d 85 f6 0f 85 2e 03 00 > > Dec 14 10:17:26 liondog kernel: [12312.144671] RIP [<ffffffff8106d1da>] __lock_acquire+0x19d/0x173f > > Dec 14 10:17:26 liondog kernel: [12312.144674] RSP <ffff88022d1b3cb8> > > Dec 14 10:17:26 liondog kernel: [12312.144676] CR2: 00000110850fc085 > > Dec 14 10:17:26 liondog kernel: [12312.144678] ---[ end trace b215ad3559f4bac0 ]--- > > That code disassembles to > > > 0: 74 33 je 0x35 > 2: 80 3d 25 1b c7 00 01 cmpb $0x1,0xc71b25(%rip) # 0xc71b2e > 9: 74 2a je 0x35 > b: be a6 02 00 00 mov $0x2a6,%esi > 10: 48 c7 c7 d1 8b 5e 81 mov $0xffffffff815e8bd1,%rdi > 17: e8 af dc fc ff callq 0xfffffffffffcdccb > 1c: c6 05 0b 1b c7 00 01 movb $0x1,0xc71b0b(%rip) # 0xc71b2e > 23: eb 10 jmp 0x35 > 25: 49 89 d6 mov %rdx,%r14 > 28:* 49 8b 16 mov (%r14),%rdx <-- trapping instruction > 2b: 49 39 ce cmp %rcx,%r14 > 2e: 0f 18 0a prefetcht0 (%rdx) > 31: 75 bc jne 0xffffffffffffffef > 33: eb 09 jmp 0x3e > > which I think matches up with this: > > movq (%rdx), %rsi # class_293->hash_entry.next, D.31652 > cmpq %rcx, %rdx # hash_head, class > prefetcht0 (%rsi) # D.31652 > jne .L449 #, > jmp .L560 # yes it does, __lock_acquire+0x19d = 0x4eb6, i.e. 4ea5: e8 00 00 00 00 callq 4eaa <__lock_acquire+0x191> 4eaa: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # 4eb1 <__lock_acquire+0x198> 4eb1: eb 10 jmp 4ec3 <__lock_acquire+0x1aa> 4eb3: 49 89 d6 mov %rdx,%r14 4eb6: 49 8b 16 mov (%r14),%rdx <------------------- 4eb9: 49 39 ce cmp %rcx,%r14 4ebc: 0f 18 0a prefetcht0 (%rdx) 4ebf: 75 bc jne 4e7d <__lock_acquire+0x164> 4ec1: eb 09 jmp 4ecc <__lock_acquire+0x1b3> > which looks like one of the "list_for_each_entry()" uses of that > hash_head. In fact, building lockdep.lst and matching against that > 0x2a6 constant (it's a warn_slowpath_null thing and is the line > number), we can pinpoint exactly which one it seems to be. Also true: hash_head = classhashentry(key); ffffffff8106d17f: 48 89 c1 mov %rax,%rcx ffffffff8106d182: 48 c1 e1 3f shl $0x3f,%rcx ffffffff8106d186: 48 01 ca add %rcx,%rdx ffffffff8106d189: 48 c1 ea 34 shr $0x34,%rdx ffffffff8106d18d: 48 c1 e2 04 shl $0x4,%rdx ffffffff8106d191: 48 8d 8a 00 00 00 00 lea 0x0(%rdx),%rcx ffffffff8106d194: R_X86_64_32S .bss+0x5dfeb0 /* * We can walk the hash lockfree, because the hash only * grows, and we are careful when adding entries to the end: */ list_for_each_entry(class, hash_head, hash_entry) { ffffffff8106d198: 4c 8b b2 00 00 00 00 mov 0x0(%rdx),%r14 ffffffff8106d19b: R_X86_64_32S .bss+0x5dfeb0 ffffffff8106d19f: eb 39 jmp ffffffff8106d1da <__lock_acquire+0x19d> if (class->key == key) { ffffffff8106d1a1: 49 39 46 20 cmp %rax,0x20(%r14) ffffffff8106d1a5: 75 30 jne ffffffff8106d1d7 <__lock_acquire+0x19a> WARN_ON_ONCE(class->name != lock->name); ffffffff8106d1a7: 48 8b 43 18 mov 0x18(%rbx),%rax ffffffff8106d1ab: 49 39 86 a0 01 00 00 cmp %rax,0x1a0(%r14) ffffffff8106d1b2: 74 33 je ffffffff8106d1e7 <__lock_acquire+0x1aa> ffffffff8106d1b4: 80 3d 00 00 00 00 01 cmpb $0x1,0x0(%rip) # ffffffff8106d1bb <__lock_acquire+0x17e> ffffffff8106d1b6: R_X86_64_PC32 .bss+0x10004b ffffffff8106d1bb: 74 2a je ffffffff8106d1e7 <__lock_acquire+0x1aa> ffffffff8106d1bd: be a6 02 00 00 mov $0x2a6,%esi ffffffff8106d1c2: 48 c7 c7 00 00 00 00 mov $0x0,%rdi ffffffff8106d1c5: R_X86_64_32S .rodata.str1.1+0x36c ffffffff8106d1c9: e8 00 00 00 00 callq ffffffff8106d1ce <__lock_acquire+0x191> ffffffff8106d1ca: R_X86_64_PC32 warn_slowpath_null+0xfffffffffffffffc ffffffff8106d1ce: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # ffffffff8106d1d5 <__lock_acquire+0x198> ffffffff8106d1d0: R_X86_64_PC32 .bss+0x10004b ffffffff8106d1d5: eb 10 jmp ffffffff8106d1e7 <__lock_acquire+0x1aa> /* * We can walk the hash lockfree, because the hash only * grows, and we are careful when adding entries to the end: */ list_for_each_entry(class, hash_head, hash_entry) { ffffffff8106d1d7: 49 89 d6 mov %rdx,%r14 ffffffff8106d1da: 49 8b 16 mov (%r14),%rdx ffffffff8106d1dd: 49 39 ce cmp %rcx,%r14 ffffffff8106d1e0: 0f 18 0a prefetcht0 (%rdx) ffffffff8106d1e3: 75 bc jne ffffffff8106d1a1 <__lock_acquire+0x164> ffffffff8106d1e5: eb 09 jmp ffffffff8106d1f0 <__lock_acquire+0x1b3> struct list_head *hash_head; struct lock_class *class; unsigned long flags; %r14 is actually %rdx and it gets computed in classhashentry(key) and I'd guess here that some of the elements on that hash bucket disappears/has disappeared, thus causing the GP. Also, 00000110850fc085 doesn't look like a proper virtual address to me. > Afaik, it seems to be this code in look_up_lock_class: > > /* > * We can walk the hash lockfree, because the hash only > * grows, and we are careful when adding entries to the end: > */ > list_for_each_entry(class, hash_head, hash_entry) { > if (class->key == key) { > WARN_ON_ONCE(class->name != lock->name); > return class; > } > } > > Maybe the RCU list use in lockdep isn't entirely safe? > > Added Peter and Ingo to the cc. It does look like some lockdep race. The problem is, I don't have a recipe for re-triggering this - I'll have to watch out for lockups... > Or then it's some general memory corruption, of course. That just > happened to hit the lockdep data structures. That would explain your > subsequent radeon GP fault too. If it is that, it would be much harder to debug. Again, I'll have to watch out if it repeats itself. It could very well be that it never reappears, who knows... Thanks. -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 2010-12-14 20:29 ` Linus Torvalds 2010-12-14 22:42 ` Borislav Petkov @ 2010-12-15 9:52 ` Peter Zijlstra 1 sibling, 0 replies; 4+ messages in thread From: Peter Zijlstra @ 2010-12-15 9:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: Borislav Petkov, Alex Deucher, x86, lkml, Ingo Molnar On Tue, 2010-12-14 at 12:29 -0800, Linus Torvalds wrote: > which looks like one of the "list_for_each_entry()" uses of that > hash_head. In fact, building lockdep.lst and matching against that > 0x2a6 constant (it's a warn_slowpath_null thing and is the line > number), we can pinpoint exactly which one it seems to be. Afaik, it > seems to be this code in look_up_lock_class: > > /* > * We can walk the hash lockfree, because the hash only > * grows, and we are careful when adding entries to the end: > */ > list_for_each_entry(class, hash_head, hash_entry) { > if (class->key == key) { > WARN_ON_ONCE(class->name != lock->name); > return class; > } > } > > Maybe the RCU list use in lockdep isn't entirely safe? > > Added Peter and Ingo to the cc. It does look like some lockdep race. > > Or then it's some general memory corruption, of course. That just > happened to hit the lockdep data structures. That would explain your > subsequent radeon GP fault too. Typically such crashes in lockdep are indeed indicative of a scribble, typically a use after free with slab poisoning. But I'll try and run through that code later today to see if I can spot anything. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-12-15 9:53 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-14 9:40 BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1081 Borislav Petkov 2010-12-14 20:29 ` Linus Torvalds 2010-12-14 22:42 ` Borislav Petkov 2010-12-15 9:52 ` Peter Zijlstra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox