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.
(In reply to Giuseppe Ghibò from comment #0) > Reverting those patches fixes the memory exhaustion problem during > compilation. The important thing to know would be: does the same problem occur with mainline (e.g. 6.8-rc4) as well. Could you test this please?
From a quick test the same problem doesn't occur in 6.8-rc4.
Forwarded by mail: https://lore.kernel.org/all/f9f89284-0f48-4971-ad8d-86938a82fafc@leemhuis.info/
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #3) > Forwarded by mail: > https://lore.kernel.org/all/f9f89284-0f48-4971-ad8d-86938a82fafc@leemhuis. > info/ Please check that thread: could you confirm that the problem happens when compiling drivers/media/pci/solo6x10/solo6x10-offsets.h? Or is it something else?
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #4) > Please check that thread: could you confirm [...] Likely not needed anymore, but can't hurt if you have a minute.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #4) > (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from > comment #3) > > Forwarded by mail: > > https://lore.kernel.org/all/f9f89284-0f48-4971-ad8d-86938a82fafc@leemhuis. > > info/ > > Please check that thread: could you confirm that the problem happens when > compiling drivers/media/pci/solo6x10/solo6x10-offsets.h? Or is it something > else? Yes, sort of. I'll try to build with CONFIG_VIDEO_SOLO6X10 disabled and the minmax patchset applied to see whether there are other missed.
With CONFIG_VIDEO_SOLO6X10 disabled it compiles smooth without memory exaustion errors. Now trying with the patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/media/pci/solo6x10/solo6x10-offsets.h?id=31e97d7c9ae3de072d7b424b2cf706a03ec10720 Pretty weird that the max() used in solo6x10-offsets.h like max(min(...,...),...) would cause that big problem; Though the min() or max() macro has always been fragile (because of being macros, at least when defined with the ternary operator, I wonder if we can extract a minimal test case.
Confirming with the media-solo6x10-replace-max-a-min-b-c-by-clamp-b-a-c.patch the above problem doesn't occur anymore.
Closing this, as a fix was included in 6.6.17.