linux-kernel - Re: [patch 5/8] x86: use this_cpu_xxx to replace percpu

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1203061015060.20871@router.home>
Date:	Tue, 6 Mar 2012 10:33:32 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andrew Morton <akpm@...ux-foundation.org>, tglx@...utronix.de,
	hpa@...or.com, alex.shi@...el.com, sfr@...b.auug.org.au,
	tj@...nel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [patch 5/8] x86: use this_cpu_xxx to replace percpu_xxx funcs

On Tue, 6 Mar 2012, Ingo Molnar wrote:

> > All percpu_xxx() functions get removed.
>
> Fair enough - then please see my namespace comments for the
> other patch, before we start spreading these APIs to hundreds of
> places ...

Its already almost everywhere... This removes some of the last holdouts.

> Also, IMHO the lack of debugging API is troubling as well.

For that there would need to be some basic understanding as to what is
going on here. These are fundamentally atomic style operations and I keep
hearing that people want to check if they are in a preempt section etc.
I do not see how that is possible for the this_cpu_ops.

However, checks could be done this for the __this_cpu_ops (which rely on
the processor not changing during their execution for their fallback
implementation, therefore preempt should be off) by simply adding a check
to the basic macros (add to __this_cpu_ptr for example). The problem is
then that there needs to be an audit first to see if there are cases where
we run into trouble with such an approach. There are situations in which
the use of __this_cpu ops is legitimate for other reasons if no concurrent
per cpu access can occur or we cannot be moved to a different processor
(because the process pinned to a processor f.e.)

> Thomas found a couple of really, really hairy this_cpu related
> bugs.

Well yeah if one uses per cpu operations and then allows execution to
occur on a different processor then one will not operate on the same
entity. The same issue would have occurred if they had used the old
percpu operations.
--
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/