Linux-Fsdevel Archive on
help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Tetsuo Handa <>,
	Dave Hansen <>
Cc: Linux Kernel Mailing List <>,
	linux-mm <>,
	"the arch/x86 maintainers" <>,
	linux-fsdevel <>,
	Michal Hocko <>
Subject: Re: [mm 4.15-rc8] Random oopses under memory pressure.
Date: Mon, 15 Jan 2018 18:14:49 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jan 15, 2018 at 5:15 PM, Tetsuo Handa
<> wrote:
> I can't reproduce this with CONFIG_FLATMEM=y . But I'm not sure whether
> we are hitting a bug in CONFIG_SPARSEMEM=y code, for the bug is highly
> timing dependent.

Hmm. Maybe. But sparsemem really also generates *much* more complex
code particularly for the pfn_to_page() case.

It also has much less testing. For example, on x86-64 we do use
sparsemem, but we use the VMEMMAP version of sparsemem: the version
that does *not* play really odd and complex games with that whole

I've always felt like sparsemem was really damn complicated.  The
whole "section_mem_map" encoding is really subtle and odd.

And considering that we're getting what appears to be a invalid page,
in one of the more complicated sequences that very much does that
whole pfn_to_page(), I really wonder.

I wonder if somebody could add some VM_BUG_ON() checks to the
non-vmemmap case of sparsemem in include/asm-generic/memory_model.h.

Because this:

  #define __pfn_to_page(pfn)                              \
  ({      unsigned long __pfn = (pfn);                    \
          struct mem_section *__sec = __pfn_to_section(__pfn);    \
          __section_mem_map_addr(__sec) + __pfn;          \

is really subtle, and if we have some case where we pass in an
out-of-range pfn, or some case where we get the section wrong (because
the pfn is between sections or whatever due to some subtle setup bug),
things will really go sideways.

The reason I was hoping you could do this for FLATMEM is that it's
much easier to verify the pfn range in that case.  The sparsemem cases
really makes it much nastier.

That said, all of that code is really old. Most of it goes back to
-05/06 or so. But since you seem to be able to reproduce at least back
to 4.8, I guess this bug does back years too.

But I'm adding Dave Hansen explicitly to the cc, in case he has any
ideas. Not because I blame him, but he's touched the sparsemem code
fairly recently, so maybe he'd have some idea on adding sanity
checking to the sparsemem version of pfn_to_page().

> I dont know why but selecting CONFIG_FLATMEM=y seems to avoid a different bug
> where bootup of qemu randomly fails at

Hmm. That looks very different indeed. But if CONFIG_SPARSEMEM
(presumably together with HIGHMEM) has some odd off-by-one corner case
or similar, who knows *what* issues it could trigger.


To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to  For more info on Linux MM,
see: .
Don't email: <a href=mailto:""> </a>

  reply	other threads:[~2018-01-16  2:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
2018-01-11 14:11         ` [mm? 4.15-rc7] " Tetsuo Handa
2018-01-11 14:21           ` Michal Hocko
2018-01-11 14:37             ` Tetsuo Handa
2018-01-12  1:31             ` [mm " Tetsuo Handa
2018-01-12  1:42               ` Linus Torvalds
2018-01-12 11:22                 ` Tetsuo Handa
2018-01-14 11:54                   ` Tetsuo Handa
2018-01-15 23:05                     ` Linus Torvalds
2018-01-16  1:15                       ` [mm 4.15-rc8] " Tetsuo Handa
2018-01-16  2:14                         ` Linus Torvalds [this message]
2018-01-16  8:06                           ` Dave Hansen
2018-01-16  8:37                             ` Ingo Molnar
2018-01-16 19:30                             ` Linus Torvalds
2018-01-16 17:33                           ` Tetsuo Handa
2018-01-16 19:34                             ` Linus Torvalds
2018-01-17 11:08                               ` Tetsuo Handa
2018-01-11 18:11           ` [mm? 4.15-rc7] " Linus Torvalds
2018-01-11 20:59             ` Tetsuo Handa

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 \
    --in-reply-to='' \ \ \ \ \ \ \ \ \
    --subject='Re: [mm 4.15-rc8] Random oopses under memory pressure.' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).