[regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation
Hi Greg, Sasha, and David,
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.
Note, you have to use bugzilla to reach the reporter, as I sadly[1] can not CCed them in mails like this.
[TLDR for the rest of this mail: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form.]
BTW, let me use this mail to also add the report to the list of tracked regressions to ensure it's doesn't fall through the cracks:
#regzbot introduced: 204c653d5d0c79940..9487d93f172acef https://bugzilla.kernel.org/show_bug.cgi?id=218484 #regzbot title: minmax: virtual memory exhausted in 6.6.16 with i586 chroot #regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
[1] because bugzilla.kernel.org tells users upon registration their "email address will never be displayed to logged out users"
On Mon, Feb 12, 2024 at 05:16:58PM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
Hi Greg, Sasha, and David,
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.
Note, you have to use bugzilla to reach the reporter, as I sadly[1] can not CCed them in mails like this.
[TLDR for the rest of this mail: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form.]
BTW, let me use this mail to also add the report to the list of tracked regressions to ensure it's doesn't fall through the cracks:
#regzbot introduced: 204c653d5d0c79940..9487d93f172acef https://bugzilla.kernel.org/show_bug.cgi?id=218484 #regzbot title: minmax: virtual memory exhausted in 6.6.16 with i586 chroot #regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
[1] because bugzilla.kernel.org tells users upon registration their "email address will never be displayed to logged out users"
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.
What file is causing the compiler to crash? Is it some video or media driver?
thanks,
greg k-h
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.
What file is causing the compiler to crash? Is it some video or media driver?
HTH, Ciao, Thorsten
On Tue, Feb 13, 2024 at 04:01:23PM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
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.
Yes, that's the one, thanks!
I've queued it up now.
greg k-h
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.
But 31e97d7c9ae3de needs backporting as well.
(Someone really ought to look at the solo6x10 driver. It really ought to be caching some of those values. I also suspect (not looked) that if the values do get clamped (above) it just wont work at all.)
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
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
linux-stable-mirror@lists.linaro.org
-
David Laight -
Greg KH -
Linux regression tracking (Thorsten Leemhuis)