linux.git/include/asm-generic/bitops, branch v7.2-rc1

bitops: Define generic___bitrev8/16/32 for reuse

2026-05-28T15:39:16+00:00

Define generic___bitrev8/16/32 using the implementation in
, so they can be reused in ,
such as RISCV.

Reviewed-by: Yury Norov 
Signed-off-by: Jinjie Ruan 
Signed-off-by: Yury Norov

bitops: use common function parameter names

2026-05-20T15:18:27+00:00

Fix the function prototypes to use the common parameter name 'addr'
instead of 'p' (common to arch-specific implementations of these
functions).
This avoids the kernel-doc warnings:

Warning: include/asm-generic/bitops/lock.h:19 function parameter 'p'
 not described in 'arch_test_and_set_bit_lock'
Warning: include/asm-generic/bitops/lock.h:41 function parameter 'p'
 not described in 'arch_clear_bit_unlock'
Warning: include/asm-generic/bitops/lock.h:59 function parameter 'p'
 not described in 'arch___clear_bit_unlock'

Fixes: 84c6591103db ("locking/atomics, asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*()")
Signed-off-by: Randy Dunlap 
Signed-off-by: Yury Norov

asm-generic/bitops: Fix a comment typo in instrumented-atomic.h

2026-03-23T17:33:51+00:00

The comment after the '#endif' at the end of the instrumented-atomic.h
is a typo.  The "NON_ATOMIC" part should be "ATOMIC".  Fix it.

Signed-off-by: Kai Huang 
Signed-off-by: Yury Norov

bitops: Add __attribute_const__ to generic ffs()-family implementations

2025-09-08T21:58:50+00:00

While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used in the initializer macro, but since it wasn't marked with
__attribute__const__, the compiler had to assume the function might
change variable states as a side-effect (which is not true for ffs(),
which provides deterministic math results).

Add missing __attribute_const__ annotations to generic implementations of
ffs(), __ffs(), fls(), and __fls() functions. These are pure mathematical
functions that always return the same result for the same input with no
side effects, making them eligible for compiler optimization.

Build tested with x86_64 defconfig using GCC 14.2.0, which should validate
the implementations when used by ARM, ARM64, LoongArch, Microblaze,
NIOS2, and SPARC32 architectures.

Link: https://github.com/KSPP/linux/issues/364 [1]
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20250804164417.1612371-2-kees@kernel.org
Signed-off-by: Kees Cook

bitops: Change function return types from long to int

2024-05-03T15:04:50+00:00

Change the return types of bitops functions (ffs, fls, and fns) from
long to int. The expected return values are in the range [0, 64], for
which int is sufficient.

Additionally, int aligns well with the return types of the corresponding
__builtin_* functions, potentially reducing overall type conversions.

Many of the existing bitops functions already return an int and don't
need to be changed. The bitops functions in arch/ should be considered
separately.

Adjust some return variables to match the function return types.

With GCC 13 and defconfig, these changes reduced the size of a test
kernel image by 5,432 bytes on arm64 and by 248 bytes on riscv; there
were no changes in size on x86_64, powerpc, or m68k.

Signed-off-by: Thorsten Blum 
Signed-off-by: Arnd Bergmann

riscv: Avoid code duplication with generic bitops implementation

2024-01-25T01:25:36+00:00

There's code duplication between the fallback implementation for bitops
__ffs/__fls/ffs/fls API and the generic C implementation in
include/asm-generic/bitops/. To avoid this duplication, this patch renames
the generic C implementation by adding a "generic_" prefix to them, then we
can use these generic APIs as fallback.

Suggested-by: Geert Uytterhoeven 
Signed-off-by: Xiao Wang 
Reviewed-by: Charlie Jenkins 
Link: https://lore.kernel.org/r/20231112094421.4014931-1-xiao.w.wang@intel.com
Signed-off-by: Palmer Dabbelt

mm: delete checks for xor_unlock_is_negative_byte()

2023-10-18T21:34:17+00:00

Architectures which don't define their own use the one in
asm-generic/bitops/lock.h.  Get rid of all the ifdefs around "maybe we
don't have it".

Link: https://lkml.kernel.org/r/20231004165317.1061855-15-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) 
Acked-by: Geert Uytterhoeven 
Cc: Albert Ou 
Cc: Alexander Gordeev 
Cc: Andreas Dilger 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Heiko Carstens 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: Richard Henderson 
Cc: Sven Schnelle 
Cc: "Theodore Ts'o" 
Cc: Thomas Bogendoerfer 
Cc: Vasily Gorbik 
Signed-off-by: Andrew Morton

bitops: add xor_unlock_is_negative_byte()

2023-10-18T21:34:16+00:00

Replace clear_bit_and_unlock_is_negative_byte() with
xor_unlock_is_negative_byte().  We have a few places that like to lock a
folio, set a flag and unlock it again.  Allow for the possibility of
combining the latter two operations for efficiency.  We are guaranteed
that the caller holds the lock, so it is safe to unlock it with the xor. 
The caller must guarantee that nobody else will set the flag without
holding the lock; it is not safe to do this with the PG_dirty flag, for
example.

Link: https://lkml.kernel.org/r/20231004165317.1061855-8-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) 
Cc: Albert Ou 
Cc: Alexander Gordeev 
Cc: Andreas Dilger 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Geert Uytterhoeven 
Cc: Heiko Carstens 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: Richard Henderson 
Cc: Sven Schnelle 
Cc: "Theodore Ts'o" 
Cc: Thomas Bogendoerfer 
Cc: Vasily Gorbik 
Signed-off-by: Andrew Morton

locking/atomic: treewide: use raw_atomic*_()

2023-06-05T07:57:20+00:00

Now that we have raw_atomic*_() definitions, there's no need to use
arch_atomic*_() definitions outside of the low-level atomic
definitions.

Move treewide users of arch_atomic*_() over to the equivalent
raw_atomic*_().

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Kees Cook 
Link: https://lore.kernel.org/r/20230605070124.3741859-19-mark.rutland@arm.com

wait_on_bit: add an acquire memory barrier

2022-08-26T16:30:25+00:00

There are several places in the kernel where wait_on_bit is not followed
by a memory barrier (for example, in drivers/md/dm-bufio.c:new_read).

On architectures with weak memory ordering, it may happen that memory
accesses that follow wait_on_bit are reordered before wait_on_bit and
they may return invalid data.

Fix this class of bugs by introducing a new function "test_bit_acquire"
that works like test_bit, but has acquire memory ordering semantics.

Signed-off-by: Mikulas Patocka 
Acked-by: Will Deacon 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds