linux-kernel - ACPI scheduling while atomic (was: Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1251108153.28030.21.camel@pc1117.cambridge.arm.com>
Date:	Mon, 24 Aug 2009 11:02:33 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-acpi@...r.kernel.org
Subject: ACPI scheduling while atomic (was: Re: [PATCH] kmemleak: Fix
	scheduling-while-atomic bug)

On Mon, 2009-08-24 at 08:10 +0800, Ming Lei wrote:
> 2009/8/23 Catalin Marinas <catalin.marinas@....com>:
> > On Sun, 2009-08-23 at 10:48 +0800, Ming Lei wrote:
> >> [    0.006569] ACPI: Core revision 20090521
> >> [    0.011476] BUG: scheduling while atomic: swapper/0/0x10000002
> >> [    0.011558] no locks held by swapper/0.
> >> [    0.011561] Modules linked in:
> >> [    0.011566] Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #141
> >> [    0.011569] Call Trace:
> >> [    0.011577]  [<ffffffff81070bb7>] ? __debug_show_held_locks+0x22/0x24
> >> [    0.011584]  [<ffffffff8103d4ba>] __schedule_bug+0x77/0x7c
> >> [    0.011590]  [<ffffffff812da32f>] schedule+0xd6/0xa3f
> >> [    0.011596]  [<ffffffff810e4b9b>] ? kmem_cache_free+0xe2/0x158
> >> [    0.011600]  [<ffffffff810717e2>] ? trace_hardirqs_on_caller+0x12d/0x158
> >> [    0.011604]  [<ffffffff8107181a>] ? trace_hardirqs_on+0xd/0xf
> >> [    0.011609]  [<ffffffff8103e3f0>] __cond_resched+0x29/0x47
> >> [    0.011614]  [<ffffffff812dae24>] _cond_resched+0x29/0x34
> >> [    0.011620]  [<ffffffff811da90a>] acpi_ps_complete_op+0x246/0x25c
> >> [    0.011625]  [<ffffffff811db024>] acpi_ps_parse_loop+0x704/0x860
> >> [    0.011630]  [<ffffffff811da200>] acpi_ps_parse_aml+0x9f/0x2de
> >> [    0.011635]  [<ffffffff811d9181>] acpi_ns_one_complete_parse+0x101/0x11c
> >> [    0.011640]  [<ffffffff811d91bd>] acpi_ns_parse_table+0x21/0x3c
> >> [    0.011645]  [<ffffffff811d67e3>] acpi_ns_load_table+0x4f/0x94
> >> [    0.011650]  [<ffffffff811dd14a>] acpi_load_tables+0x72/0x133
> >> [    0.011656]  [<ffffffff8153c592>] acpi_early_init+0x60/0xf5
> >> [    0.011661]  [<ffffffff81519cb0>] start_kernel+0x38b/0x3a0
> >> [    0.011666]  [<ffffffff81519140>] ? early_idt_handler+0x0/0x71
> >> [    0.011670]  [<ffffffff815192a3>] x86_64_start_reservations+0xaa/0xae
> >> [    0.011675]  [<ffffffff8151939e>] x86_64_start_kernel+0xf7/0x106
> >
> > I looked at the traces and there are no kmemleak calls. It's either that
> > kmemleak is disabled or the error is not on a kmemleak path. It looks
> > more like an ACPI bug to me.
> >
> > Can you try only with slab debugging enabled (without kmemleak or
> > kmemcheck)? IIRC someone else reported a similar issue a few weeks ago.
> 
> If I only disabled kmemleak, the kernel does not print the warning, so I suppose
> it is related with kmemleak.

I can't really see how kmemleak gets involved in here. Maybe you could
just enable some of the features turned on by kmemleak like STACKTRACE
and see if you still get the error.

For x86-64 you may need this patch - http://lkml.org/lkml/2009/8/16/269

> Attachment is the .config,  hope it is usable to help to fix the warning.

Thanks but I don't have such hardware to test and I don't get this error
on x86-32.

Looking at the code, the acpi_ps_complete_op() function calls the
ACPI_PREEMPTION_POINT() macro which expands to a cond_resched() call if
IRQs aren't disabled. The IRQs are probably enabled at that point but it
seems that the context is atomic.

I cc'ed the ACPI people, maybe they can help with some suggestions 

Thanks.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/