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

[Nathan Chancellor]

On Fri, Jul 28, 2023 at 01:00:30PM +0200, Arnd Bergmann wrote:
> On Thu, Jul 27, 2023, at 23:36, Nathan Chancellor wrote:
> > Hi Tiezhu and Arnd,
> >
> > On Thu, Jun 22, 2023 at 10:13:38PM +0800, Tiezhu Yang wrote:
> >> Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0
> >> in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are
> >> usable, it is probably fine to unify the definition of __BITS_PER_LONG as
> >> (__CHAR_BIT__ * __SIZEOF_LONG__) in asm-generic uapi bitsperlong.h.
> >> 
> >> In order to keep safe and avoid regression, only unify uapi bitsperlong.h
> >> for some archs such as arm64, riscv and loongarch which are using newer
> >> toolchains that have the definitions of __CHAR_BIT__ and __SIZEOF_LONG__.
> >> 
> >> Suggested-by: Xi Ruoyao <xry111 at xry111.site>
> >> Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.camel@xry111.site/
> >> Suggested-by: Arnd Bergmann <arnd at arndb.de>
> >> Link: https://lore.kernel.org/linux-arch/a3a4f48a-07d4-4ed9-bc53-5d383428bdd2@app.fastmail.com/
> >> Signed-off-by: Tiezhu Yang <yangtiezhu at loongson.cn>
> >> ---
> 
> >
> > I think this change has backwards compatibility concerns, as it breaks
> > building certain host tools on the stable releases (at least 6.4 and
> > 6.1, as that is where I noticed this). I see the following error on my
> > aarch64 system:
> >
> >   $ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- 
> > mrproper defconfig prepare
> >   In file included from /usr/include/asm/bitsperlong.h:1,
> >                    from /usr/include/asm-generic/int-ll64.h:12,
> >                    from /usr/include/asm-generic/types.h:7,
> >                    from /usr/include/asm/types.h:1,
> >                    from tools/include/linux/types.h:13,
> >                    from tools/arch/x86/include/asm/orc_types.h:9,
> >                    from scripts/sorttable.h:96,
> >                    from scripts/sorttable.c:201:
> >   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
> >         |  ^~~~~
> 
> Thanks for the report. I'm still struggling to figure out what
> exactly is going wrong here, and if this is a bug in the patch
> I merged, or an existing bug that now causes a build failure instead
> of some other problem.

Totally understandable, I was really confused at first too.

> > A reverse bisect of 6.4 to 6.5-rc1 points to this patch. This Fedora
> > rawhide container has kernel-headers 6.5.0-0.rc2.git0.1.fc39 and the
> > error disappears when I downgrade to 6.4.0-0.rc7.git0.1.fc39. I have not
> > done a ton of triage/debugging so far, as I am currently hunting down
> > other regressions, but I figured I would get an initial report out,
> > since I noticed it when validating LLVM from the new release/17.x
> > branch. If there is any additional information I can provide or patches
> > I can test, I am more than happy to do so.
> 
> One thing I think is going wrong here is that scripts/sorttable.c is
> meant to run on the host (arm64) but includes the target (x86)
> orc_Types.h header and the kernel-internal asm/bitsperlong.h instead

Right. I will note sorttable is not the only utility that has this
issue, I see the same problem coming from several files in
tools/lib/subcmd when building several different architectures and
arch/x86/entry/vdso/vdso2c.c at the very least.

> of the uapi version. The sanity check in the kernel-side header
> is intended to cross-check the CONFIG_64BIT value against the
> __BITS_PER_LONG constant from the header.
> 
> My first guess would be that this only worked by accident if the headers
> defaulted to "#define __BITS_PER_LONG 32" in and #undef CONFIG_64BIT"
> when include/generated/autoconf.h, but now the __BITS_PER_LONG value
> is actually correct.

That seems like a reasonable theory. I am still busy looking into other
things today but I can try to double back to this on Monday if you don't
make any progress.

Cheers,
Nathan