linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Thomas Garnier <thgarnie@google.com>,
	Jeff Moyer <jmoyer@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>
Subject: Re: KASLR causes intermittent boot failures on some systems
Date: Tue, 25 Apr 2017 07:56:20 +0800	[thread overview]
Message-ID: <20170424235620.GB11734@x1> (raw)
In-Reply-To: <CAPcyv4iPS1Gz_rkG1-d59ve+kaVyWs_jHZ9wdSaC0R17MaxWsg@mail.gmail.com>

On 04/24/17 at 04:18pm, Dan Williams wrote:
> On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He <bhe@redhat.com> wrote:
> > On 04/24/17 at 01:52pm, Dan Williams wrote:
> [..]
> >> When using the memmap= parameter we're using this call by default:
> >>
> >>         } else if (pmem_should_map_pages(dev)) {
> >>                 addr = devm_memremap_pages(dev, &nsio->res,
> >>                                 &q->q_usage_counter, NULL);
> >>                 pmem->pfn_flags |= PFN_MAP;
> >>         } else
> >>
> >> ...where we are assuming that the memmap= parameter does not specify a
> >> range-size that will exhaust all of system-memory just to hold the
> >> struct page array.
> >
> > Yeah, according to my debugging tracking, it goes as Dan said. And the
> > is_ram is REGION_DISJOINT. And till arch_add_memory, the parameters
> > passed to arch_add_memory are "arch_add_memory, align_start:0x10000000000, align_size:0x3000000000",
> > seems it's going well.
> >
> > Hi Dan,
> >
> > I am always confused that in devm_memremap_pages, the passed in
> > parameter altmap is NULL, while it used devres_alloc_node to allocate a
> > page_map and that page_map contained a altmap instance, not pointer.
> > Then the addr range were inserted into pgmap_radix with value of
> > page_map. Why later in __add_pages, to_vmem_altmap() return NULL
> > according to my debugging code?
> 
> We expect altmap to always be NULL in this case. The only time it is
> not NULL is when the namespace is configured to allocate the struct
> page array from capacity on the namespace itself. I.e. instead of
> allocating struct page from page allocator pages the driver creates an
> altmap and vmemmap_populate_hugepages() uses that to allocate the
> array from "alternate" capacity.
> 
> You can force this by running:
> 
>     ndctl create-namespace -f -e namespace0.0 -m memory -M dev
> 
> ...which says "put the struct page map on the device".

Ah, got. It only assigned page_map->altmap to pgmap->altmap when the
passed in altmap is not NULL. 

pgmap->altmap = &page_map->altmap;

I didn't notice this. Thanks for telling. So in this case without
alternate capacity, it will allocate from normal ram memory struct page
array.

Thanks
Baoquan

  reply	other threads:[~2017-04-24 23:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 14:41 KASLR causes intermittent boot failures on some systems Jeff Moyer
2017-04-07 14:49 ` Thomas Garnier
2017-04-07 14:51   ` Jeff Moyer
2017-04-07 21:25 ` Kees Cook
2017-04-10 15:49   ` Jeff Moyer
2017-04-10 18:13     ` Kees Cook
2017-04-10 18:22       ` Jeff Moyer
2017-04-10 19:03         ` Kees Cook
2017-04-10 19:18           ` Jeff Moyer
2017-04-08  2:51 ` Baoquan He
2017-04-08  4:08 ` Baoquan He
2017-04-08  7:02   ` Dan Williams
2017-04-08  7:52     ` Baoquan He
2017-04-10 15:57   ` Jeff Moyer
2017-04-12  8:24 ` Dave Young
2017-04-12  8:27   ` Dave Young
2017-04-12  8:40   ` Dave Young
2017-04-12 12:52     ` Jeff Moyer
2017-04-19 13:36 ` Baoquan He
2017-04-19 14:27   ` Thomas Garnier
2017-04-19 14:34     ` Dan Williams
2017-04-19 14:56       ` Baoquan He
2017-04-19 14:56       ` Thomas Garnier
2017-04-19 14:55     ` Baoquan He
2017-04-20 13:26     ` Baoquan He
2017-04-24 20:37       ` Thomas Garnier
2017-04-24 20:52         ` Dan Williams
2017-04-24 23:07           ` Baoquan He
2017-04-24 23:18             ` Dan Williams
2017-04-24 23:56               ` Baoquan He [this message]
2017-04-25  0:41             ` Thomas Garnier
2017-04-25  1:18               ` Baoquan He
2017-05-01 11:32 ` Baoquan He

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=20170424235620.GB11734@x1 \
    --to=bhe@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=mingo@kernel.org \
    --cc=thgarnie@google.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;
as well as URLs for NNTP newsgroup(s).