lkml.org 
[lkml]   [2009]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fix quilt merge error in acpi-cpufreq.c

* Linus Torvalds <torvalds@linux-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


\
 
 \ /
  Last update: 2009-04-15 18:45    [W:0.114 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site