Skip to content
Snippets Groups Projects
  1. Sep 28, 2022
  2. May 17, 2022
  3. Feb 11, 2022
    • Mark Rutland's avatar
      atomics: Fix atomic64_{read_acquire,set_release} fallbacks · dc1b4df0
      Mark Rutland authored
      
      Arnd reports that on 32-bit architectures, the fallbacks for
      atomic64_read_acquire() and atomic64_set_release() are broken as they
      use smp_load_acquire() and smp_store_release() respectively, which do
      not work on types larger than the native word size.
      
      Since those contain compiletime_assert_atomic_type(), any attempt to use
      those fallbacks will result in a build-time error. e.g. with the
      following added to arch/arm/kernel/setup.c:
      
      | void test_atomic64(atomic64_t *v)
      | {
      |        atomic64_set_release(v, 5);
      |        atomic64_read_acquire(v);
      | }
      
      The compiler will complain as follows:
      
      | In file included from <command-line>:
      | In function 'arch_atomic64_set_release',
      |     inlined from 'test_atomic64' at ./include/linux/atomic/atomic-instrumented.h:669:2:
      | ././include/linux/compiler_types.h:346:38: error: call to '__compiletime_assert_9' declared with attribute error: Need native word sized stores/loads for atomicity.
      |   346 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |       |                                      ^
      | ././include/linux/compiler_types.h:327:4: note: in definition of macro '__compiletime_assert'
      |   327 |    prefix ## suffix();    \
      |       |    ^~~~~~
      | ././include/linux/compiler_types.h:346:2: note: in expansion of macro '_compiletime_assert'
      |   346 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |       |  ^~~~~~~~~~~~~~~~~~~
      | ././include/linux/compiler_types.h:349:2: note: in expansion of macro 'compiletime_assert'
      |   349 |  compiletime_assert(__native_word(t),    \
      |       |  ^~~~~~~~~~~~~~~~~~
      | ./include/asm-generic/barrier.h:133:2: note: in expansion of macro 'compiletime_assert_atomic_type'
      |   133 |  compiletime_assert_atomic_type(*p);    \
      |       |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      | ./include/asm-generic/barrier.h:164:55: note: in expansion of macro '__smp_store_release'
      |   164 | #define smp_store_release(p, v) do { kcsan_release(); __smp_store_release(p, v); } while (0)
      |       |                                                       ^~~~~~~~~~~~~~~~~~~
      | ./include/linux/atomic/atomic-arch-fallback.h:1270:2: note: in expansion of macro 'smp_store_release'
      |  1270 |  smp_store_release(&(v)->counter, i);
      |       |  ^~~~~~~~~~~~~~~~~
      | make[2]: *** [scripts/Makefile.build:288: arch/arm/kernel/setup.o] Error 1
      | make[1]: *** [scripts/Makefile.build:550: arch/arm/kernel] Error 2
      | make: *** [Makefile:1831: arch/arm] Error 2
      
      Fix this by only using smp_load_acquire() and smp_store_release() for
      native atomic types, and otherwise falling back to the regular barriers
      necessary for acquire/release semantics, as we do in the more generic
      acquire and release fallbacks.
      
      Since the fallback templates are used to generate the atomic64_*() and
      atomic_*() operations, the __native_word() check is added to both. For
      the atomic_*() operations, which are always 32-bit, the __native_word()
      check is redundant but not harmful, as it is always true.
      
      For the example above this works as expected on 32-bit, e.g. for arm
      multi_v7_defconfig:
      
      | <test_atomic64>:
      |         push    {r4, r5}
      |         dmb     ish
      |         pldw    [r0]
      |         mov     r2, #5
      |         mov     r3, #0
      |         ldrexd  r4, [r0]
      |         strexd  r4, r2, [r0]
      |         teq     r4, #0
      |         bne     484 <test_atomic64+0x14>
      |         ldrexd  r2, [r0]
      |         dmb     ish
      |         pop     {r4, r5}
      |         bx      lr
      
      ... and also on 64-bit, e.g. for arm64 defconfig:
      
      | <test_atomic64>:
      |         bti     c
      |         paciasp
      |         mov     x1, #0x5
      |         stlr    x1, [x0]
      |         ldar    x0, [x0]
      |         autiasp
      |         ret
      
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarBoqun Feng <boqun.feng@gmail.com>
      Link: https://lore.kernel.org/r/20220207101943.439825-1-mark.rutland@arm.com
      dc1b4df0
  4. Dec 10, 2021
  5. Jul 16, 2021
  6. May 26, 2021
  7. Nov 07, 2020
    • Ingo Molnar's avatar
      locking/atomics: Regenerate the atomics-check SHA1's · a70a04b3
      Ingo Molnar authored
      
      The include/asm-generic/atomic-instrumented.h checksum got out
      of sync, so regenerate it. (No change to actual code.)
      
      Also make scripts/atomic/gen-atomics.sh executable, to make
      it easier to use.
      
      The auto-generated atomic header signatures are now fine:
      
        thule:~/tip> scripts/atomic/check-atomics.sh
        thule:~/tip>
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Paul E. McKenney <paulmck@kernel.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a70a04b3
  8. Oct 12, 2020
  9. Oct 07, 2020
  10. Aug 24, 2020
  11. Jun 25, 2020
  12. Jun 11, 2020
  13. Mar 21, 2020
  14. Jan 07, 2020
  15. Nov 16, 2019
  16. Jun 25, 2019
  17. Apr 19, 2019
  18. Feb 13, 2019
    • Mark Rutland's avatar
      locking/atomics: Check atomic headers with sha1sum · 0cf264b3
      Mark Rutland authored and Ingo Molnar's avatar Ingo Molnar committed
      
      We currently check the atomic headers at build-time to ensure they
      haven't been modified directly, and these checks require regenerating
      the headers in full. As this takes a few seconds, even when
      parallelized, this is too slow to run for every kernel build.
      
      Instead, we can generate a hash of each header as we generate them,
      which we can cheaply check at build time (~0.16s for all headers).
      
      This patch does so, updating headers with their hashes using the new
      gen-atomics.sh script. As some users apparently build the kernel wihout
      coreutils, lacking sha1sum, the checks are skipped in this case.
      Presumably, most developers have a working coreutils installation.
      
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: anders.roxell@linaro.org
      Cc: linux-kernel@vger.kernel.rg
      Cc: naresh.kamboju@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0cf264b3
  19. Feb 11, 2019
  20. Nov 01, 2018
    • Ingo Molnar's avatar
      locking/atomics: Fix scripts/atomic/ script permissions · 4d8e5cd2
      Ingo Molnar authored
      
      Mark all these scripts executable.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: linuxdrivers@attotech.com
      Cc: dvyukov@google.com
      Cc: boqun.feng@gmail.com
      Cc: arnd@arndb.de
      Cc: aryabinin@virtuozzo.com
      Cc: glider@google.com
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4d8e5cd2
    • Mark Rutland's avatar
      locking/atomics: Check generated headers are up-to-date · 8d325880
      Mark Rutland authored and Ingo Molnar's avatar Ingo Molnar committed
      
      Now that all the generated atomic headers are in place, it would be good
      to ensure that:
      
      a) the headers are up-to-date when scripting changes.
      
      b) developers don't directly modify the generated headers.
      
      To ensure both of these properties, let's add a Kbuild step to check
      that the generated headers are up-to-date.
      
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxdrivers@attotech.com
      Cc: dvyukov@google.com
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: arnd@arndb.de
      Cc: aryabinin@virtuozzo.com
      Cc: glider@google.com
      Link: http://lkml.kernel.org/r/20180904104830.2975-6-mark.rutland@arm.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8d325880
    • Mark Rutland's avatar
      locking/atomics: Add common header generation files · ace9bad4
      Mark Rutland authored and Ingo Molnar's avatar Ingo Molnar committed
      
      To minimize repetition, to allow for future rework, and to ensure
      regularity of the various atomic APIs, we'd like to automatically
      generate (the bulk of) a number of headers related to atomics.
      
      This patch adds the infrastructure to do so, leaving actual conversion
      of headers to subsequent patches. This infrastructure consists of:
      
      * atomics.tbl - a table describing the functions in the atomics API,
        with names, prototypes, and metadata describing the variants that
        exist (e.g fetch/return, acquire/release/relaxed). Note that the
        return type is dependent on the particular variant.
      
      * atomic-tbl.sh - a library of routines useful for dealing with
        atomics.tbl (e.g. querying which variants exist, or generating
        argument/parameter lists for a given function variant).
      
      * gen-atomic-fallback.sh - a script which generates a header of
        fallbacks, covering cases where architecture omit certain functions
        (e.g. omitting relaxed variants).
      
      * gen-atomic-long.sh - a script which generates wrappers providing the
        atomic_long API atomic of the relevant atomic or atomic64 API,
        ensuring the APIs are consistent.
      
      * gen-atomic-instrumented.sh - a script which generates atomic* wrappers
        atop of arch_atomic* functions, with automatically generated KASAN
        instrumentation.
      
      * fallbacks/* - a set of fallback implementations for atomics, which
        should be used when no implementation of a given atomic is provided.
        These are used by gen-atomic-fallback.sh to generate fallbacks, and
        these are also used by other scripts to determine the set of optional
        atomics (as required to generate preprocessor guards correctly).
      
        Fallbacks may use the following variables:
      
        ${atomic}     atomic prefix: atomic/atomic64/atomic_long, which can be
      		used to derive the atomic type, and to prefix functions
      
        ${int}        integer type: int/s64/long
      
        ${pfx}        variant prefix, e.g. fetch_
      
        ${name}       base function name, e.g. add
      
        ${sfx}        variant suffix, e.g. _return
      
        ${order}      order suffix, e.g. _relaxed
      
        ${atomicname} full name, e.g. atomic64_fetch_add_relaxed
      
        ${ret}        return type of the function, e.g. void
      
        ${retstmt}    a return statement (with a trailing space), unless the
                      variant returns void
      
        ${params}     parameter list for the function declaration, e.g.
                      "int i, atomic_t *v"
      
        ${args}       argument list for invoking the function, e.g. "i, v"
      
        ... for clarity, ${ret}, ${retstmt}, ${params}, and ${args} are
        open-coded for fallbacks where these do not vary, or are critical to
        understanding the logic of the fallback.
      
      The MAINTAINERS entry for the atomic infrastructure is updated to cover
      the new scripts.
      
      There should be no functional change as a result of this patch.
      
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxdrivers@attotech.com
      Cc: dvyukov@google.com
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: arnd@arndb.de
      Cc: aryabinin@virtuozzo.com
      Cc: glider@google.com
      Link: http://lkml.kernel.org/r/20180904104830.2975-2-mark.rutland@arm.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ace9bad4
Loading