[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

bugzilla-daemon at kernel.org bugzilla-daemon at kernel.org
Fri Oct 27 10:40:59 AEDT 2023


https://bugzilla.kernel.org/show_bug.cgi?id=215389

Erhard F. (erhard_f at mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #300354|0                           |1
        is obsolete|                            |
 Attachment #300977|0                           |1
        is obsolete|                            |
 Attachment #301337|0                           |1
        is obsolete|                            |
 Attachment #301639|0                           |1
        is obsolete|                            |

--- Comment #40 from Erhard F. (erhard_f at mailbox.org) ---
Created attachment 305297
  --> https://bugzilla.kernel.org/attachment.cgi?id=305297&action=edit
dmesg (5.5-rc5, PowerMac G4 DP)

Re-visiting this bug as it's reproducible on v6.6-rc7.

This time I tried the other way round. CONFIG_VMAP_STACK was added for ppc with
commit cd08f109e26231b279bcc0388428afcac6408ec6 (at about kernel v5.5-rc5
time). So I did a git checkout cd08f109e26231b279bcc0388428afcac6408ec6 and
started from there with a further reduced kernel .config.

I added two additional patches to get the G4 to boot with VMAP_STACK enabled:
4119622 "powerpc/32s: Fix kasan_early_hash_table() for CONFIG_VMAP_STACK" and
232ca1e "powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK".

Then I burdened the memory subsystem with "stress -c 2 --vm 2 --vm-bytes 896M"
as before and hit the issue in less than 20 sec. Not hitting the issue means my
G4 runs "stress -c 2 --vm 2 --vm-bytes 896M" for about half an hour without
side effects.

So it looks like the issue was here from the start when CONFIG_VMAP_STACK was
added for ppc. (see dmesg)

I don't hit the issue when:
   1. nr_cpus=1 is set + VMAP_STACK enabled
   2. VMAP_STACK disabled

Setting LOWMEM_SIZE to 0x28000000 does not seem to have an effect on it.


This bug really plays hard to get... T'll do further KCSAN checks in recent
kernels and open separate issues if KCSAN digs up something useful.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.


More information about the Linuxppc-dev mailing list