linux-dev/arch/x86/include/asm/bitops.h, branch linus/master

include: move find.h from asm_generic to linux

2022-01-15T16:47:31Z

find_bit API and bitmap API are closely related, but inclusion paths are different - include/asm-generic and include/linux, correspondingly. In the past it made a lot of troubles due to circular dependencies and/or undefined symbols. Fix this by moving find.h under include/linux. Signed-off-by: Yury Norov Tested-by: Wolfram Sang Acked-by: Geert Uytterhoeven

x86, kcsan: Remove __no_kcsan_or_inline usage

2020-06-15T12:10:08Z

Now that KCSAN relies on -tsan-distinguish-volatile we no longer need the annotation for constant_test_bit(). Remove it. Signed-off-by: Peter Zijlstra (Intel)

Rebase locking/kcsan to locking/urgent

2020-06-11T18:02:46Z

Merge the state of the locking kcsan branch before the read/write_once() and the atomics modifications got merged. Squash the fallout of the rebase on top of the read/write once and atomic fallback work into the merge. The history of the original branch is preserved in tag locking-kcsan-2020-06-02. Signed-off-by: Thomas Gleixner

x86: bitops: fix build regression

2020-05-23T17:26:31Z

This is easily reproducible via CC=clang + CONFIG_STAGING=y + CONFIG_VT6656=m. It turns out that if your config tickles __builtin_constant_p via differences in choices to inline or not, these statements produce invalid assembly: $ cat foo.c long a(long b, long c) { asm("orb %1, %0" : "+q"(c): "r"(b)); return c; } $ gcc foo.c foo.c: Assembler messages: foo.c:2: Error: `%rax' not allowed with `orb' Use the `%b` "x86 Operand Modifier" to instead force register allocation to select a lower-8-bit GPR operand. The "q" constraint only has meaning on -m32 otherwise is treated as "r". Not all GPRs have low-8-bit aliases for -m32. Fixes: 1651e700664b4 ("x86: Fix bitops.h warning with a moved cast") Reported-by: kernelci.org bot Suggested-by: Andy Shevchenko Suggested-by: Brian Gerst Suggested-by: H. Peter Anvin Suggested-by: Ilie Halip Signed-off-by: Nick Desaulniers Signed-off-by: Andrew Morton Tested-by: Sedat Dilek Tested-by: Nathan Chancellor [build, clang-11] Reviewed-by: Nathan Chancellor Reviewed-By: Brian Gerst Reviewed-by: Jesse Brandeburg Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Marco Elver Cc: "Paul E. McKenney" Cc: Andrey Ryabinin Cc: Luc Van Oostenryck Cc: Masahiro Yamada Cc: Daniel Axtens Cc: "Peter Zijlstra (Intel)" Link: http://lkml.kernel.org/r/20200508183230.229464-1-ndesaulniers@google.com Link: https://github.com/ClangBuiltLinux/linux/issues/961 Link: https://lore.kernel.org/lkml/20200504193524.GA221287@google.com/ Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#x86Operandmodifiers Signed-off-by: Linus Torvalds

Merge tag 'v5.7-rc1' into locking/kcsan, to resolve conflicts and refresh

2020-04-13T07:44:39Z

Resolve these conflicts: arch/x86/Kconfig arch/x86/kernel/Makefile Do a minor "evil merge" to move the KCSAN entry up a bit by a few lines in the Kconfig to reduce the probability of future conflicts. Signed-off-by: Ingo Molnar

x86: Fix bitops.h warning with a moved cast

2020-03-18T11:30:19Z

Fix many sparse warnings when building with C=1. These are useless noise from the bitops.h file and getting rid of them helps developers make more use of the tools and possibly find real bugs. When the kernel is compiled with C=1, there are lots of messages like: arch/x86/include/asm/bitops.h:77:37: warning: cast truncates bits from constant value (ffffff7f becomes 7f) CONST_MASK() is using a signed integer "1" to create the mask which is later cast to (u8), in order to yield an 8-bit value for the assembly instructions to use. Simplify the expressions used to clearly indicate they are working on 8-bit values only, which still keeps sparse happy without an accidental promotion to a 32 bit integer. The warning was occurring because certain bitmasks that end with a bit set next to a natural boundary like 7, 15, 23, 31, end up with a mask like 0x7f, which then results in sign extension due to the integer type promotion rules[1]. It was really only clear_bit() that was having problems, and it was only on some bit checks that resulted in a mask like 0xffffff7f being generated after the inversion. Verify with a test module (see next patch) and assembly inspection that the fix doesn't introduce any change in generated code. [ bp: Massage. ] Signed-off-by: Jesse Brandeburg Signed-off-by: Borislav Petkov Reviewed-by: Andy Shevchenko Acked-by: Luc Van Oostenryck Acked-by: Peter Zijlstra (Intel) Link: https://stackoverflow.com/questions/46073295/implicit-type-promotion-rules [1] Link: https://lkml.kernel.org/r/20200310221747.2848474-1-jesse.brandeburg@intel.com

Merge tag 'v5.5-rc4' into locking/kcsan, to resolve conflicts

2019-12-30T07:10:51Z

Conflicts: init/main.c lib/Kconfig.debug Signed-off-by: Ingo Molnar

x86, kcsan: Enable KCSAN for x86

2019-11-16T15:23:16Z

This patch enables KCSAN for x86, with updates to build rules to not use KCSAN for several incompatible compilation units. Signed-off-by: Marco Elver Acked-by: Paul E. McKenney Signed-off-by: Paul E. McKenney

kasan: support instrumented bitops combined with generic bitops

2019-11-07T02:15:39Z

Currently bitops-instrumented.h assumes that the architecture provides atomic, non-atomic and locking bitops (e.g. both set_bit and __set_bit). This is true on x86 and s390, but is not always true: there is a generic bitops/non-atomic.h header that provides generic non-atomic operations, and also a generic bitops/lock.h for locking operations. powerpc uses the generic non-atomic version, so it does not have it's own e.g. __set_bit that could be renamed arch___set_bit. Split up bitops-instrumented.h to mirror the atomic/non-atomic/lock split. This allows arches to only include the headers where they have arch-specific versions to rename. Update x86 and s390. (The generic operations are automatically instrumented because they're written in C, not asm.) Suggested-by: Christophe Leroy Reviewed-by: Christophe Leroy Signed-off-by: Daniel Axtens Acked-by: Marco Elver Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190820024941.12640-1-dja@axtens.net

x86/bitops: Use __builtin_constant_p() directly instead of IS_IMMEDIATE()

2019-07-23T11:44:18Z

__builtin_constant_p(nr) is used everywhere now. It does not make much sense to define IS_IMMEDIATE() as its alias. Signed-off-by: Masahiro Yamada Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20190723074415.26811-1-yamada.masahiro@socionext.com