linux-kernel - Re: [RFC][PATCH 2/5] mm: Switch mod_state() to __this_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1109201806220.2723@ionos>
Date:	Tue, 20 Sep 2011 18:51:38 +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:
> > 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.
> 
> Counter increments have been done this way for a very long time. This is
> a pretty well established way of doing things in the kernel that was
> expanded and made better by avoid preempt disable/enable around these per
> cpu pointer increments.

This still can be done, when the functions are actually having
sensible names and annotations.

> > 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?
> 
> Bogus conversions?

Is the list I posted not enough?

The usage of this_cpu_read() in functions which require to be called
with preemption or interrupts disabled is pointless and worse it
actually removed debug functionality in some places which used
smp_processor_id() before.

I do not care at all whether this_cpu_read() on x86 does not have the
preempt_enable/disable() pair, but I care a lot about the correctness
of the code and debugability.

> > So stop defending that trainwreck and help out with fixing the mess
> > you created in a proper and debugable way!
> 
> You want debugging to ensure that this_cpu ops always access the intended
> per cpu area? But the point of these operations is to be used in kernel
> locations where the use of any per cpu area is satisfactory.

The point is that the whole design assumes that people get it correct
and you spent not a split second to provide any means of debugability
for this. Now you argue in circles about your performance numbers and
let others deal with the fallout and refuse to think about a sensible
solution to the problem.

It does not matter at all what you intended and what people should do,
but it does matter very much what unintentional and undebugable
wreckage can be caused by it.

We spent huge efforts to make locks debugable and we still have people
getting it wrong and you expect that something as complex as the per
cpu stuff is just correct by definition.

And the problem of this_cpu & co starts with the naming convention.

this_cpu_*() is patently wrong. It should be: random_cpu_*() or
any_cpu_*(). This way you could have avoided confusion in the first
place and made it entirely clear what the interfaces are about.

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/