linux-kernel - Re: [PATCH 00/48] percpu: Consistent per cpu operations V4

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: <20140304142759.a6849728754eb553b0bd33d3@linux-foundation.org>
Date:	Tue, 4 Mar 2014 14:27:59 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Tejun Heo <tj@...nel.org>, akpm@...uxfoundation.org,
	rostedt@...dmis.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 00/48] percpu: Consistent per cpu operations V4

On Fri, 14 Feb 2014 14:18:41 -0600 Christoph Lameter <cl@...ux.com> wrote:

> Can we please get this merged? The first patch alone would at least define
> the functions required to enable the merging of the rest in any order and
> through any tree.

This series is structured as

[patch 1]: make changes whcih trigger lots of runtime warnings
[patch 2-n]: fix up those warnings

yes?

So we're proposing adding a 48-patch bisection hole in which scary
warnings will be emitted.

I guess that's liveable with - we *could* fix it, by starting out with
do-nothing wrappers, then all the fixes and then finish up with patches
which turn do-nothing-wrapeprs into do-something-functions.  But I'm
not sure that the resulting obscuration is worth the effort.

> The kernel has never been audited to ensure that this_cpu operations are
> consistently used throughout the kernel. The code generated in many
> places can be improved through the use of this_cpu operations (which uses
> a segment register for relocation of per cpu offsets instead of
> performing address calculations).
> 
> The patch set also addresses various consistency issues in general with
> the per cpu macros.
> 
> A. The semantics of __this_cpu_ptr() differs from this_cpu_ptr only
>    because checks are skipped. This is typically shown through a raw_
>    prefix. So this patch set changes the places where __this_cpu_ptr()
>    is used to raw_cpu_ptr().
> 
> B. There has been the long term wish by some that __this_cpu operations
>    would check for preemption. However, there are cases where preemption
>    checks need to be skipped. This patch set adds raw_cpu operations that
>    do not check for preemption and then adds preemption checks to the
>    __this_cpu operations.
> 
> C. The use of __get_cpu_var is always a reference to a percpu variable
>    that can also be handled via a this_cpu operation. This patch set
>    replaces all uses of __get_cpu_var with this_cpu operations.
> 
> D. We can then use this_cpu RMW operations in various places replacing
>    sequences of instructions by a single one.
> 
> E. The use of this_cpu operations throughout will allow other arches than
>    x86 to implement optimized references and RMV operations to work with
>    per cpu local data.
> 
> F. The use of this_cpu operations opens up the possibility to
>    further optimize code that relies on synchronization through
>    per cpu data.
> 
> 
> The patch set works in a couple of stages:
> 
> I. Patch 1 adds the additional raw_cpu operations and raw_cpu_ptr().
>     Also converts the existing __this_cpu_xx_# primitive in the x86
>     code to raw_cpu_xx_#.
> 
> II. Patch 2-4 use the raw_cpu operations in places that would give
>      us false positives once they are enabled.
> 
> III. Patch 5 adds preemption checks to __this_cpu operations to allow
>     checking if preemption is properly disabled when these functions
>     are used.
> 
> IV. Patches 6-20 are patches that simply replace uses of __get_cpu_var
>    with this_cpu_ptr. They do not depend on any changes to the percpu
>    code. No preemption tests are skipped if they are applied.
> 
> V. Patches 21-46 are conversion patches that use this_cpu operations
>    in various kernel subsystems/drivers or arch code.

That all seems desirable.

> VI. Patches 47/48 remove no longer used functions (__this_cpu_ptr
>     and __get_cpu_var).  These should only be applied after all the
>     conversion patches have made it and after we have done additional
>     passes through the kernel to ensure that none of the uses of these
>     functions remain.

Yes, I'll skip those two.

In linux-next arch/arm/mach-msm/timer.c gets moved to
drivers/clocksource/qcom-timer.c, which I fixed up.  Apart from that it
all still merges OK...
--
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/