[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121213163233.GA2728@htj.dyndns.org>
Date: Thu, 13 Dec 2012 08:32:33 -0800
From: Tejun Heo <tj@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
tglx@...utronix.de, peterz@...radead.org,
paulmck@...ux.vnet.ibm.com, rusty@...tcorp.com.au,
mingo@...nel.org, akpm@...ux-foundation.org, namhyung@...nel.org,
vincent.guittot@...aro.org, sbw@....edu, amit.kucheria@...aro.org,
rostedt@...dmis.org, rjw@...k.pl, wangyun@...ux.vnet.ibm.com,
xiaoguangrong@...ux.vnet.ibm.com, nikunj@...ux.vnet.ibm.com,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v4 1/9] CPU hotplug: Provide APIs to prevent CPU
offline from atomic context
Hello, Oleg.
On Thu, Dec 13, 2012 at 05:17:09PM +0100, Oleg Nesterov wrote:
> Hmm. I thought that __this_cpu_* must be safe under preempt_disable().
> IOW, I thought that, say, this_cpu_inc() is "equal" to preempt_disable +
> __this_cpu_inc() correctness-wise.
this_cpu_inc() equals local_irq_save() + __this_cpu_inc().
> And. I thought that this_cpu_inc() is safe wrt interrupt, like local_t.
Yes, it is safe.
> But when I try to read the comments percpu.h, I am starting to think that
> even this_cpu_inc() is not safe if irq handler can do the same?
>
> Confused...
Yeah, the comment is confusing and the way these macros are defined
doesn't help. There used to be three variants and it looks like we
didn't update the comment while removing the preempt safe ones. Gotta
clean those up. Anyways, yes, this_cpu_*() are safe against irqs.
Thanks.
--
tejun
--
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