LKML Archive on
help / color / mirror / Atom feed
From: Pavel Tatashin <>
To: Andrew Morton <>
Cc: Steven Sistare <>,
	Daniel Jordan <>,
	LKML <>,, Michal Hocko <>,
	Linux Memory Management List <>,,,, Steven Rostedt <>,
	Fengguang Wu <>,
	Dennis Zhou <>
Subject: Re: [PATCH v2] mm: access to uninitialized struct page
Date: Tue, 08 May 2018 14:44:51 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> Gulp.  Let's hope that nothing in mm_init() requires that trap_init()
> has been run.  What happens if something goes wrong during mm_init()
> and the architecture attempts to raise a software exception, hits a bus
> error, div-by-zero, etc, etc?  Might there be hard-to-discover
> dependencies in such a case?

Hi Andrew,

Unfortunately, mm_init() requires trap_init(). And, because trap_init() is
arch specific, I do not see a way to simply fix  trap_init(). So, we need
to find a different fix for the above problem. And, the current fix needs
to be removed from mm.

BTW, the bug was not introduced by:
c9e97a1997fb ("mm: initialize pages on demand during boot")

Fengguang Wu, reproduced this bug with builds prior to when this patch was
added. So, I think that while my patch may make this problem happen more
frequently, the problem itself is older. Basically, it depends on value of

One way to quickly fix this issue is to disable deferred struct pages when
the following combination is true:

RANDOMIZE_BASE means we do not know from what PFN struct pages are going to
be required before mm_init().
CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_VMEMMAP means that page_to_pfn() will
use information from page->flags to get section number, and thus require
accessing "struct pages"


  parent reply	other threads:[~2018-05-08 14:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 20:26 Pavel Tatashin
2018-04-30 23:26 ` Andrew Morton
2018-04-30 23:58   ` Steven Rostedt
2018-05-01  0:01     ` Andrew Morton
2018-05-08 14:44   ` Pavel Tatashin [this message]
2018-05-04  8:27 ` [v2] " Andrei Vagin
2018-05-04 12:47   ` Pavel Tatashin
2018-05-04 14:50     ` Steven Rostedt
2018-05-04 16:01     ` Andrei Vagin
2018-05-04 16:03       ` Pavel Tatashin
2018-05-04 17:49         ` Andy Shevchenko
2018-05-05  1:04           ` Fengguang Wu

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 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2] mm: access to uninitialized struct page' \

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