linux-kernel - Re: [PATCH v3 1/2] asm-generic: Unify uapi bitsperlong.h for arm64, riscv and loongarch

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <e7a792d9-39b9-440a-9c22-99e25b25a396@app.fastmail.com>
Date:   Sat, 29 Jul 2023 09:59:23 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Nathan Chancellor" <nathan@...nel.org>
Cc:     "Tiezhu Yang" <yangtiezhu@...ngson.cn>,
        linux-arm-kernel@...ts.infradead.org,
        linux-riscv@...ts.infradead.org, loongarch@...ts.linux.dev,
        Linux-Arch <linux-arch@...r.kernel.org>, bpf@...r.kernel.org,
        linux-perf-users@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v3 1/2] asm-generic: Unify uapi bitsperlong.h for arm64, riscv and
 loongarch

On Sat, Jul 29, 2023, at 01:44, Nathan Chancellor wrote:
> On Fri, Jul 28, 2023 at 10:56:38PM +0200, Arnd Bergmann wrote:

>     DESCEND objtool
>   In file included from 
> /usr/include/aarch64-linux-gnu/asm/bitsperlong.h:1,
>                    from /usr/include/asm-generic/int-ll64.h:12,
>                    from /usr/include/asm-generic/types.h:7,
>                    from /usr/include/aarch64-linux-gnu/asm/types.h:1,
>                    from /linux-stable/tools/include/linux/types.h:13,
>                    from 
> /linux-stable/tools/arch/x86/include/asm/orc_types.h:9,
>                    from /linux-stable/scripts/sorttable.h:96,
>                    from /linux-stable/scripts/sorttable.c:201:
>   /linux-stable/tools/include/asm-generic/bitsperlong.h:14:2: error: 
> #error Inconsistent word size. Check asm/bitsperlong.h
>      14 | #error Inconsistent word size. Check asm/bitsperlong.h
>         |  ^~~~~
>   make[3]: *** [/linux-stable/scripts/Makefile.host:114: 
> scripts/sorttable] Error 1
>   ...
>
>> I also noticed that your command line includes CROSS_COMPILE=x86_64-linux-
>> rather than CROSS_COMPILE=x86_64-linux-gnu-
>
> Right, as I was reproducing this with your kernel.org GCC for
> CROSS_COMPILE and Fedora's GCC for HOSTCC, since I wanted to make sure
> this was not some issue with clang (which it does not appear to be).

Ok, it's beginning to make more sense to me now. I see
that the tools/arch/x86/include/asm/orc_types.h comes from
the x86_64 target build and is intentional, as sorttable.c
needs to access the ORC information. Here the Makefile does

ifdef CONFIG_UNWINDER_ORC
ifeq ($(ARCH),x86_64)
ARCH := x86
endif
HOSTCFLAGS_sorttable.o += -I$(srctree)/tools/arch/x86/include
HOSTCFLAGS_sorttable.o += -DUNWINDER_ORC_ENABLED
endif

in order to get the ORC definitions from asm/orc_types.h, but
then it looks like it also gets the uapi/asm/bitsperlong.h
header from there which contains

#if defined(__x86_64__) && !defined(__ILP32__)
# define __BITS_PER_LONG 64
#else
# define __BITS_PER_LONG 32
#endif

and this would set __BITS_PER_LONG to 32 on arm64.

However, I don't see this actually being included on my
machine. Can you dump the sorttable.c preprocessor output
with your setup, using -fdirectives-only, so we can see
which of the two (__BITS_PER_LONG or BITS_PER_LONG) is
actually wrong and triggers the sanity check?

What I see on my machine is that both definitions come
from the local tools/include/ headers, not from the
installed system headers, so I'm still doing something
wrong in my installation:

./tools/include/uapi/asm-generic/bitsperlong.h
#define __BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)

./tools/include/asm-generic/bitsperlong.h
#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)

Neither of these files actually contains the sanity
check in linux-6.5-rc3, and comparing these is clearly
nonsensical, as they are defined the same way (rather
than checking CONFIG_64BIT), but also I don't see why
there is both a uapi/ version and a non-uapi version
in what is meant to be a userspace header.

     Arnd