[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070514121818.00dfc679.akpm@linux-foundation.org>
Date: Mon, 14 May 2007 12:18:18 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Heiko Carstens <heiko.carstens@...ibm.com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
randy.dunlap@...cle.com, paulus@...ba.org,
benh@...nel.crashing.org, David Miller <davem@...emloft.net>,
Andi Kleen <ak@...e.de>
Subject: Re: [patch] Let smp_call_function_single return -EBUSY.
On Mon, 14 May 2007 12:11:37 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:
> > This of course raises another question: it is not clear in which context
> > the smp_call_function* functions are supposed to be called. Should it be
> > with preemption disabled or is preemption enabled allowed as well?
> > If calling with preemption enabled is allowed then the powerpc implementation
> > is broken, since smp_processor_id() as well as num_online_cpus() may change
> > while they are accessed.
>
> These are all excellent questions. And important ones.
erk, I see your point. If a caller is calling this with preemption enabled
then the current thread might at any time migrate onto the target CPU,
causing the smp_call_function_single() attempt to fail. So the effects of
that call are basically a random crapshoot.
Often but not always, any code which is hanging onto a variable called
"cpu" while preemption enabled is buggy.
So yes, I'd say that from a sanity-of-implementation POV and for general
defensiveness, we should require that the called of
smp_call_function_single() has disabled preemption.
What a crock.
-
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/
Powered by blists - more mailing lists