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-next>] [day] [month] [year] [list]
Message-Id: <1402590209-31610-1-git-send-email-tj@kernel.org>
Date:	Thu, 12 Jun 2014 12:23:17 -0400
From:	Tejun Heo <tj@...nel.org>
To:	cl@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCHSET percpu/for-3.17] percpu: clean up percpu accessor and operation definitions

Hello,

Percpu accessor and operation definitions are very difficult to
follow.  Things are scattered around different header files without
specific reasons.  Definitions of different types are mixed and the
ordering sometimes is conventional.  Different definitions use
different styles and sometimes lack visual consistency for no good
reason.

The issues go deeper than skin-deep.  There's no clear distinction
between arch-specific and generic part of implementation making it
impossible for the generic layer to impose common feature or
restriction on top of arch-specific overrides.  The arch override
mechanism is broken in itself too. __this_cpu_*() operations are
defined in terms of raw_cpu_*_N() sub-ops and can't be overridden, so
if an arch overrides a raw_cpu_*() operation as whole, __this_cpu_*()
will continue using the generic implementation even though
semantically it's raw_cpu_*() + preemption sanity check.

This patchset contains the following 12 patches to clean up the whole
thing.

 0001-percpu-disallow-archs-from-overriding-SHIFT_PERCPU_P.patch
 0002-percpu-introduce-arch_raw_cpu_ptr.patch
 0003-percpu-include-asm-generic-percpu.h-should-contain-o.patch
 0004-percpu-move-accessors-from-include-linux-percpu.h-to.patch
 0005-percpu-reorganize-include-linux-percpu-defs.h.patch
 0006-percpu-only-allow-sized-arch-overrides-for-raw-this-.patch
 0007-percpu-move-generic-raw-this-_cpu_-_N-definitions-to.patch
 0008-percpu-move-raw-this-_cpu_-definitions-to-include-li.patch
 0009-percpu-reorder-macros-in-percpu-header-files.patch
 0010-percpu-use-raw_cpu_-to-define-__this_cpu_.patch
 0011-percpu-preffity-percpu-header-files.patch
 0012-percpu-invoke-__verify_pcpu_ptr-from-the-generic-par.patch

0001-0005 tidy up arch overrides, shuffle definitions around so that
each percpu header file serves specific purposes.

0006 disallows whole operation overrides for raw/this_cpu_*().  No
arch is using it and it makes it impossible to distinguish
arch-specific and generic parts of percpu operation definitions.

0007-0009 continues the reorganization.

0010 makes __this_cpu_*() ops use raw_cpu_*() opst instead of reaching
into raw_cpu_*_N() sub-ops.

0011 performs a bunch of cosmetic changes to make it less of an
eyesore.

0012 moves __verify_pcpu_ptr() invocations so that they're contained
in the generic layer and it's called only once per operation.  A
recent change added a data dependency barrier to __verify_pcpu_ptr()
so this makes a minute but actual difference for archs w/ non-noop
data dependency barrier FWIW.

This patchset is on top of

  linus master c31c24b8251f ("Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux")
+ [1] [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations

diffstat follows.  Thanks.

 arch/x86/include/asm/percpu.h |    3 
 include/asm-generic/percpu.h  |  410 +++++++++++++++++++++----
 include/linux/percpu-defs.h   |  397 +++++++++++++++++++++++-
 include/linux/percpu.h        |  673 ------------------------------------------
 4 files changed, 729 insertions(+), 754 deletions(-)

--
tejun

[1] http://lkml.kernel.org/g/20140612135630.GA23606@htj.dyndns.org
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ