[regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[Linux regression tracking (Thorsten Leemhuis)]

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"

Re: [regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[Greg KH]

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

Re: [regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[Linux regression tracking (Thorsten Leemhuis)]

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

Re: [regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[Greg KH]

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

RE: [regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[David Laight]

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)

Re: [regression] linux-6.6.y, minmax: virtual memory exhausted in i586 chroot during kernel compilation

[Greg KH]

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