Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-592-ga9d4a09b4b-fm-defalarms-20230725.001-ga9d4a09b
Mime-Version: 1.0
Message-Id: <1777400a-4d9c-4bdb-9d3b-f8808ef054cc@app.fastmail.com>
In-Reply-To: <20230727213648.GA354736@dev-arch.thelio-3990X>
References: <1687443219-11946-1-git-send-email-yangtiezhu@loongson.cn>
 <1687443219-11946-2-git-send-email-yangtiezhu@loongson.cn>
 <20230727213648.GA354736@dev-arch.thelio-3990X>
Date:   Fri, 28 Jul 2023 13:00:30 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Nathan Chancellor" <nathan@kernel.org>,
        "Tiezhu Yang" <yangtiezhu@loongson.cn>
Cc:     linux-arm-kernel@lists.infradead.org,
        linux-riscv@lists.infradead.org, loongarch@lists.linux.dev,
        Linux-Arch <linux-arch@vger.kernel.org>, bpf@vger.kernel.org,
        linux-perf-users@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn
Subject: Re: [PATCH v3 1/2] asm-generic: Unify uapi bitsperlong.h for arm64, riscv and
 loongarch
Content-Type: text/plain
Precedence: bulk

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@xry111.site>
>> Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.camel@xry111.site/
>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>> Link: https://lore.kernel.org/linux-arch/a3a4f48a-07d4-4ed9-bc53-5d383428bdd2@app.fastmail.com/
>> Signed-off-by: Tiezhu Yang <yangtiezhu@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.

> 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
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.

       Arnd