On Wed, 2 Aug 2023 at 09:16, Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > We see this warning with ARCH=arm64 defconfig + CONFIG_CPU_BIG_ENDIAN=y. Oh Christ. I didn't even realize that arm64 allowed a BE config. The config option goes back to 2013 - are there actually BE user space implementations around? People, why do we do that? That's positively crazy. BE is dead and should be relegated to legacy platforms. There are no advantages to being different just for the sake of being different - any "security by obscurity" argument would be far outweighed by the inconvenience to actual users. Yes, yes, I know the aarch64 architecture technically allows BE implementations - and apparently you can even do it by exception level, which I had to look up. But do any actually exist? Does the kernel even work right in BE mode? It's really easy to miss some endianness check when all the actual hardware and use is LE, and when (for example) instruction encoding and IO is then always LE anyway. > With both clang 18.0.0 (tip of tree) and GCC 13.1.0, I don't see any > actual code generation changes in fs/namei.o with this configuration. Ok, since the main legacy platform confirmed that, I'll just apply that patch directly. I'll also do the powerpc version that Arnd pointed to at the same time, since it seems silly to pick these off one at a time. It too should just be 'unsigned long', so that the two values can be bitwise or'ed together without any questions. Linus