archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Guenter Roeck <>
Cc: Linux Kernel Mailing List <>,
	Greg Kroah-Hartman <>,
	Andi Kleen <>,
	Thomas Gleixner <>,
	Josh Poimboeuf <>,
	Dave Hansen <>,
	David Woodhouse <>,
	"the arch/x86 maintainers" <>,
	Dmitry Vyukov <>,
	Hugh Dickins <>,
	"Kirill A. Shutemov" <>,
	Andrea Arcangeli <>
Subject: Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled
Date: Fri, 17 Aug 2018 17:25:07 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck <> wrote:
> [    6.649970] random: crng init done
> [    6.689002] BUG: unable to handle kernel paging request at ffffeafffa1a0020

Hmm. Lots of bits set.

> [    6.689082] RIP: 0010:[<ffffffff8116ba10>]  [<ffffffff8116ba10>] page_remove_rmap+0x10/0x230
> [    6.689082] RSP: 0018:ffffc900007abc18  EFLAGS: 00000296
> [    6.689082] RAX: ffffea0005e58000 RBX: ffffeafffa1a0000 RCX: 0000000020200000
> [    6.689082] RDX: 00003fffffe00000 RSI: 0000000000000001 RDI: ffffeafffa1a0000

Is that RDX value the same value as PHYSICAL_PMD_PAGE_MASK?

If I did my math right, it would be, if your CPU has 46 bits of
physical memory. Might that be the case?

The reason I mention that is because we had the bug with spurious
inversion of the zero pte/pmd, fixed by

  f19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs from inversion")

and that would make a zeroed pmd entry be inverted by
PHYSICAL_PMD_PAGE_MASK, and then you get odd garbage page pointers

Maybe. I could have gotten the math wrong too, but it sounds like the
register contents _potentially_ might match up with something like
this, and then we'd zap a bogus hugepage because of some confusion.

Although then I'd have expected the bisection to hit
"x86/speculation/l1tf: Invert all not present mappings" instead of the
one you hit, so I don't know.

Plus I'd have expected the problem to have been in mainline too, and
apparently it's just the 4.4 and 4.9 backports.

Your test-case does have mprotect with PROT_NONE. Which together with
that mask that *might* be PHYSICAL_PMD_PAGE_MASK makes me think it
might be related.


  parent reply	other threads:[~2018-08-18  0:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-17 22:27 Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled Guenter Roeck
2018-08-17 22:39 ` Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabledg Andi Kleen
2018-08-17 22:47   ` Guenter Roeck
2018-08-18  0:25 ` Linus Torvalds [this message]
2018-08-18  0:44   ` Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled Guenter Roeck
2018-08-18  2:46   ` Andi Kleen
2018-08-20 16:29 ` Michal Hocko
2018-08-20 18:03   ` Andi Kleen
2018-08-20 19:12     ` Michal Hocko
2018-08-20 20:18     ` Andi Kleen
2018-08-21 13:58       ` Guenter Roeck

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).