linux-kernel - Re: Linux 6.8-rc5

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 20 Feb 2024 12:37:13 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Guenter Roeck <linux@...ck-us.net>, Matthew Auld <matthew.auld@...el.com>, 
	Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@....com>, 
	Christian König <christian.koenig@....com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.8-rc5

On Tue, 20 Feb 2024 at 11:57, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> As far as I can tell, 'ps' is never modified, so the compiler should
> be able to just treat it as a constant.

. oh, and it looks like gcc *does* manage to do that on some targets.
Or at least some versions of gcc do. Because I don't see the build
failure on 32-bit x86 with gcc-13.2.1.

And apparently neither do you (you list csky, openrisc, parisc and xtensa).

I'm not sure why those particular four architectures - maybe it's
about the compiler version, maybe it's just about some basic quality
issues wrt 64-bit support on them - but yes, gcc does do a good job of
untangling that disgusting code in many cases.

The code was still unnecessarily overly complicated, and simply not
using 'u64' is definitely the right fix here. And while gcc did end up
avoding the 64-bit divide/modulus on x86, and did end up noticing that
n_pages was a constant '48', the code generation was still showing all
the signs of doing 64-bit arithmetic for no good reason).

We have good compilers, but that's not an excuse for writing bad code.

              Linus