linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Max Schulze <max.schulze@online.de>
Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	naush@raspberrypi.com, linux-mm@kvack.org,
	akpm@linux-foundation.org
Subject: Re: BUG: Bad page map in process/Bad Swap file entry, RPI CM4 on clone syscall
Date: Wed, 24 Aug 2022 16:30:47 +0100	[thread overview]
Message-ID: <20220824153045.GA18443@willie-the-truck> (raw)
In-Reply-To: <a171a1bb-71e3-0741-a8df-db11ddc0acf7@online.de>

On Thu, Aug 18, 2022 at 07:14:12PM +0200, Max Schulze wrote:
> > On 15.08.22 16:22, Will Deacon wrote:
> >>> [20:47:09] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>> [20:48:46] BUG: Bad page map in process projecta  pte:1110111111111111 pmd:800000001c40003
> >>> [20:48:46] addr:0000007fa1c00000 vm_flags:00100073 anon_vma:ffffff805bf80d08 mapping:0000000000000000 index:7fa1c00
> >>> [20:48:46] file:(null) fault:0x0 mmap:0x0 read_folio:0x0
> 
> > 
> >> I hate to say it, but this all looks like memory corruption hitting the
> >> page table and possibly the 'struct page' array to me :/
> > 
> > Perhaps a note on the occcurence: across devices, the "bad page map"
> > differs at pte, but somehow is mostly consistent at pmd:800000001c40003
> > (though I have seen 800000001c02003 and 800000001c40003). Is this some
> > "magic value"? Because when not, I think it would be highly unlikely to
> > be the hardware.
> > 
> > It is not only my program that has the problem, I have seen
> > 
> > [Sun Aug 14 17:30:38 2022] BUG: Bad page map in process llvmpipe-3  pte:262d2626292a2627 pmd:800000001c01003
> > 
> > and
> > [Sat Aug 13 11:53:43 2022] BUG: Bad page map in process Xorg:disk$1  pte:a098a09aa29ea8a4 pmd:800000001c01003
> > [Sat Aug 13 11:53:43 2022] addr:00000055a961e000 vm_flags:200100073 anon_vma:ffffff804c07d8f8 mapping:0000000000000000 index:55a961e
> > [Sat Aug 13 11:53:43 2022] file:(null) fault:0x0 mmap:0x0 read_folio:0x0
> > 
> > 
> [..]
> 
> I am able to reproduce this on 6.0.0-rc1 . 
> It looks like vm_normal_page does not recognize the page as being "normal" (?).
> (mm/memory.c)

I think the issue is much more fundamental than that; you appear to have
page-table corruption (for example, "pte:262d2626292a2627" and
"pte:1110111111111111" are definitely corrupted) and so anything dealing
with 'struct page' derived from the physical address in the pte is going to
go wonky.

From the logs here, the pmds look ok but these are the pte values I spotted:

0x1110111111111111
0x262d2626292a2627
0xa098a09aa29ea8a4
0x212725231f242323
0x2626262023222323

which don't seem to correspond to any sort of poison, but are possibly
artifacts of repeated patterns with random bits cleared?

Will


  reply	other threads:[~2022-08-24 15:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d5f3cea4-20e6-f401-f3e7-8cb2f26033dc@online.de>
     [not found] ` <20220815142213.GA10448@willie-the-truck>
     [not found]   ` <ef144edd-facb-b49e-4482-74f4b42b1ad1@online.de>
2022-08-18 17:14     ` Max Schulze
2022-08-24 15:30       ` Will Deacon [this message]
2022-08-26  8:39         ` Aw: " max.schulze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220824153045.GA18443@willie-the-truck \
    --to=will@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=max.schulze@online.de \
    --cc=naush@raspberrypi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox