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.DEB.2.00.1109201059590.8056@router.home>
Date:	Tue, 20 Sep 2011 11:02:09 -0500 (CDT)
From:	Christoph Lameter <cl@...two.org>
To:	Thomas Gleixner <tglx@...utronix.de>
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, 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.


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

> 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.

--
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/