[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120529065248.GA2597@zhy>
Date: Tue, 29 May 2012 14:52:48 +0800
From: Yong Zhang <yong.zhang0@...il.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc: linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org,
ralf@...ux-mips.org, sshtylyov@...sta.com, david.daney@...ium.com,
Nikunj A Dadhania <nikunj@...ux.vnet.ibm.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, axboe@...nel.dk,
jeremy.fitzhardinge@...rix.com, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6/8] MIPS: call set_cpu_online() on the uping cpu with
irq disabled
On Mon, May 28, 2012 at 05:34:51PM +0530, Srivatsa S. Bhat wrote:
> No, I think you are right. Sorry for the delay in replying.
> It indeed looks like we need not use ipi_call_lock/unlock() in CPU bringup
> code..
>
> However, it does make me wonder about this:
> commit 3d4422332 introduced the generic ipi helpers, and reduced the scope
> of call_function.lock and also added the check in
> generic_smp_call_function_interrupt() to proceed only if the cpu is present
> in data->cpumask.
>
> Then, commit 3b16cf8748 converted x86 to the generic ipi helpers, but while
> doing that, it explicitly retained ipi_call_lock/unlock(), which is kind of
> surprising.. I guess it was a mistake rather than intentional.
Agree. I think it's a mistake(or leftover) too :)
Anyway, let me cook a patch to throw a stone to clear the road.
Thanks,
Yong
--
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