linux-kernel - Re: Fix quilt merge error in acpi-cpufreq.c

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Apr 2009 18:41:43 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ali Gholami Rudi <ali@...i.ir>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Dave Jones <davej@...hat.com>
Subject: Re: Fix quilt merge error in acpi-cpufreq.c


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Wed, 15 Apr 2009, Ingo Molnar wrote:
> > 
> > fuller log below. I think this is because 
> > smp_call_function_many() was essentially unused before - an IPI 
> > function should not trigger this warning, it will naturally be 
> > called in preemptible context.
> 
> Yeah, that thing is buggy. It just does "this_cpu = 
> smp_processor_id()".
> 
> But I have to admit that the breakage is documented. Both the 
> "other CPU's" part _and_ the "preemption must be disabled when 
> calling".
> 
> So it's not a bug, it's a "feature".
> 
> Which is obviously not to say that the thing isn't complete crap.
> 
> This patch should fix it - not by fixing smp_call_function_many(), 
> but by just living with the breakage. Andrew already sent out a 
> patch that just avoided the function entirely, but at least some 
> systems are likely to be able to do one single broadcast IPI with 
> this, so it's at least in theory still better to use that 
> smp_call_function_many() function, even though it has braindamaged 
> semantics.

I have no good way to trigger the bug right now: it triggered only 
once (maybe twice) in the past 2 days, and was not repeatable. But 
your patch looks like it should work around the API problem. Should 
Dave or me apply it, or will you?

But the whole code there had a pretty suspicious affinity handling 
to begin with and the cpumask changes just tried to keep the status 
quo (and even had trouble at keeping that ;-) and didnt improve it.

	Ingo
--
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/