[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1109201703560.2723@ionos>
Date: Tue, 20 Sep 2011 17:27:22 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Christoph Lameter <cl@...two.org>
cc: Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Christoph Lameter <cl@...ux.com>, Tejun Heo <htejun@...il.com>
Subject: Re: [RFC][PATCH 2/5] mm: Switch mod_state() to __this_cpu_read()
On Tue, 20 Sep 2011, Christoph Lameter wrote:
> On Tue, 20 Sep 2011, Thomas Gleixner wrote:
> > This allows us to do proper analysis of this_cpu usage and makes the
> > code understandable.
>
> Not sure what you want to check in this_cpu_xx operations. Why could
> there be issues with this_cpu_xx operations?
I want to get rid of them alltogether. They are crap by design and
prone to be used wrong without a sensible way to detect that.
> I see that __this_cpu_xx operations may not work as intended in
> preemptable contexts and there we could have more changes.
>
> this_cpu ops are single instructions that do not guarantee any consistency
> with other this_cpu_ops. If you want consistency (same per cpu area data)
> then preemption needs to be disabled.
Right, and that's the main problem. We have no fricking way to debug
this, so they should have never been there in the first place. And you
simply CANNOT prevent people from getting this wrong w/o proper
debugging and annotation. Even YOU and Tejun made bogus conversion w/o
noticing, but you expect that others get it right?
So stop defending that trainwreck and help out with fixing the mess
you created in a proper and debugable way!
Thanks,
tglx
--
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