On Tue, Feb 13, 2024 at 03:13:10PM +0000, David Laight wrote:
From: Linux regression tracking (Thorsten Leemhuis)
Sent: 13 February 2024 15:01
On 13.02.24 15:50, Greg KH wrote:
On Mon, Feb 12, 2024 at 05:16:58PM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
I noticed a regression report in bugzilla.kernel.org that seems to be specific to the linux-6.6.y series:
Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=218484 :
After upgrading to version 6.6.16, the kernel compilation on a i586 arch (on a 32bit chroot in a 64bit host) fails with a message:
virtual memory exhausted: Cannot allocate memory
this happens even lowering the number of parallel compilation threads. On a x86_64 arch the same problem doesn't occur. It's not clear whether some weird recursion is triggered that exhausts the memory, but it seems that the problem is caused by the patchset 'minmax' added to the 6.6.16 version, in particular it seems caused by these patches:
- minmax-allow-min-max-clamp-if-the-arguments-have-the-same-signedness.patch
- minmax-fix-indentation-of-__cmp_once-and-__clamp_once.patch
- minmax-allow-comparisons-of-int-against-unsigned-char-short.patch
- minmax-relax-check-to-allow-comparison-between-unsigned-arguments-and-signed-constants.patch
Reverting those patches fixes the memory exhaustion problem during compilation.
The reporter later added:
From a quick test the same problem doesn't occur in 6.8-rc4.
See the ticket for more details.
I think this was already fixed in 6.7 or Linus's tree, but I can't seem to find the commit at the moment.
I thought so as well, but was in the same situation. But your comment made me look again and now I found it: that was 31e97d7c9ae3de ("media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)"), which indeed is not yet in 6.6.y.
The code is actually (now) doing: clamp(b, clamp(c, a, d), d) but previously was four nested min()/max(). Even the a/b/c/d aren't trivial. It always was a pretty long line, but the longer expansions made it explode.
I was mildly surprised to see the minmax changes backported. Not complaining though.
They were needed to fix build errors in a different driver that was depending on the type checking changes in them. That's why I added them.
But 31e97d7c9ae3de needs backporting as well.
Now queued up, thanks.
greg k-h