mirror of
https://github.com/torvalds/linux.git
synced 2024-11-10 14:11:52 +00:00
382d4cd184
The gcc compiler translates on some architectures the 64-bit
__builtin_clzll() function to a call to the libgcc function __clzdi2(),
which should take a 64-bit parameter on 32- and 64-bit platforms.
But in the current kernel code, the built-in __clzdi2() function is
defined to operate (wrongly) on 32-bit parameters if BITS_PER_LONG ==
32, thus the return values on 32-bit kernels are in the range from
[0..31] instead of the expected [0..63] range.
This patch fixes the in-kernel functions __clzdi2() and __ctzdi2() to
take a 64-bit parameter on 32-bit kernels as well, thus it makes the
functions identical for 32- and 64-bit kernels.
This bug went unnoticed since kernel 3.11 for over 10 years, and here
are some possible reasons for that:
a) Some architectures have assembly instructions to count the bits and
which are used instead of calling __clzdi2(), e.g. on x86 the bsr
instruction and on ppc cntlz is used. On such architectures the
wrong __clzdi2() implementation isn't used and as such the bug has
no effect and won't be noticed.
b) Some architectures link to libgcc.a, and the in-kernel weak
functions get replaced by the correct 64-bit variants from libgcc.a.
c) __builtin_clzll() and __clzdi2() doesn't seem to be used in many
places in the kernel, and most likely only in uncritical functions,
e.g. when printing hex values via seq_put_hex_ll(). The wrong return
value will still print the correct number, but just in a wrong
formatting (e.g. with too many leading zeroes).
d) 32-bit kernels aren't used that much any longer, so they are less
tested.
A trivial testcase to verify if the currently running 32-bit kernel is
affected by the bug is to look at the output of /proc/self/maps:
Here the kernel uses a correct implementation of __clzdi2():
root@debian:~# cat /proc/self/maps
00010000-00019000 r-xp 00000000 08:05 787324 /usr/bin/cat
00019000-0001a000 rwxp 00009000 08:05 787324 /usr/bin/cat
0001a000-0003b000 rwxp 00000000 00:00 0 [heap]
f7551000-f770d000 r-xp 00000000 08:05 794765 /usr/lib/hppa-linux-gnu/libc.so.6
...
and this kernel uses the broken implementation of __clzdi2():
root@debian:~# cat /proc/self/maps
0000000010000-0000000019000 r-xp 00000000 000000008:000000005 787324 /usr/bin/cat
0000000019000-000000001a000 rwxp 000000009000 000000008:000000005 787324 /usr/bin/cat
000000001a000-000000003b000 rwxp 00000000 00:00 0 [heap]
00000000f73d1000-00000000f758d000 r-xp 00000000 000000008:000000005 794765 /usr/lib/hppa-linux-gnu/libc.so.6
...
Signed-off-by: Helge Deller <deller@gmx.de>
Fixes: 4df87bb7b6 ("lib: add weak clz/ctz functions")
Cc: Chanho Min <chanho.min@lge.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
44 lines
899 B
C
44 lines
899 B
C
// SPDX-License-Identifier: GPL-2.0-only
|
|
/*
|
|
* lib/clz_ctz.c
|
|
*
|
|
* Copyright (C) 2013 Chanho Min <chanho.min@lge.com>
|
|
*
|
|
* The functions in this file aren't called directly, but are required by
|
|
* GCC builtins such as __builtin_ctz, and therefore they can't be removed
|
|
* despite appearing unreferenced in kernel source.
|
|
*
|
|
* __c[lt]z[sd]i2 can be overridden by linking arch-specific versions.
|
|
*/
|
|
|
|
#include <linux/export.h>
|
|
#include <linux/kernel.h>
|
|
|
|
int __weak __ctzsi2(int val);
|
|
int __weak __ctzsi2(int val)
|
|
{
|
|
return __ffs(val);
|
|
}
|
|
EXPORT_SYMBOL(__ctzsi2);
|
|
|
|
int __weak __clzsi2(int val);
|
|
int __weak __clzsi2(int val)
|
|
{
|
|
return 32 - fls(val);
|
|
}
|
|
EXPORT_SYMBOL(__clzsi2);
|
|
|
|
int __weak __clzdi2(u64 val);
|
|
int __weak __clzdi2(u64 val)
|
|
{
|
|
return 64 - fls64(val);
|
|
}
|
|
EXPORT_SYMBOL(__clzdi2);
|
|
|
|
int __weak __ctzdi2(u64 val);
|
|
int __weak __ctzdi2(u64 val)
|
|
{
|
|
return __ffs64(val);
|
|
}
|
|
EXPORT_SYMBOL(__ctzdi2);
|