All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Thomas Garnier <thgarnie@google.com>,
	Ingo Molnar <mingo@kernel.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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
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: 70+ 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:41 ` Jeff Moyer
2017-04-07 14:49 ` Thomas Garnier
2017-04-07 14:49   ` Thomas Garnier
2017-04-07 14:51   ` Jeff Moyer
2017-04-07 14:51     ` Jeff Moyer
2017-04-07 21:25 ` Kees Cook
2017-04-07 21:25   ` Kees Cook
2017-04-10 15:49   ` Jeff Moyer
2017-04-10 15:49     ` Jeff Moyer
2017-04-10 18:13     ` Kees Cook
2017-04-10 18:13       ` Kees Cook
2017-04-10 18:22       ` Jeff Moyer
2017-04-10 18:22         ` Jeff Moyer
2017-04-10 19:03         ` Kees Cook
2017-04-10 19:03           ` Kees Cook
2017-04-10 19:18           ` Jeff Moyer
2017-04-10 19:18             ` Jeff Moyer
2017-04-08  2:51 ` Baoquan He
2017-04-08  2:51   ` Baoquan He
2017-04-08  4:08 ` Baoquan He
2017-04-08  4:08   ` Baoquan He
2017-04-08  7:02   ` Dan Williams
2017-04-08  7:02     ` Dan Williams
2017-04-08  7:52     ` Baoquan He
2017-04-08  7:52       ` Baoquan He
2017-04-10 15:57   ` Jeff Moyer
2017-04-10 15:57     ` Jeff Moyer
2017-04-12  8:24 ` Dave Young
2017-04-12  8:24   ` Dave Young
2017-04-12  8:24   ` Dave Young
2017-04-12  8:27   ` Dave Young
2017-04-12  8:27     ` Dave Young
2017-04-12  8:27     ` Dave Young
2017-04-12  8:40   ` Dave Young
2017-04-12  8:40     ` Dave Young
2017-04-12  8:40     ` Dave Young
2017-04-12 12:52     ` Jeff Moyer
2017-04-12 12:52       ` Jeff Moyer
2017-04-12 12:52       ` Jeff Moyer
2017-04-19 13:36 ` Baoquan He
2017-04-19 13:36   ` Baoquan He
2017-04-19 14:27   ` Thomas Garnier
2017-04-19 14:27     ` Thomas Garnier
2017-04-19 14:34     ` Dan Williams
2017-04-19 14:34       ` Dan Williams
2017-04-19 14:56       ` Baoquan He
2017-04-19 14:56         ` Baoquan He
2017-04-19 14:56       ` Thomas Garnier
2017-04-19 14:56         ` Thomas Garnier
2017-04-19 14:55     ` Baoquan He
2017-04-19 14:55       ` Baoquan He
2017-04-20 13:26     ` Baoquan He
2017-04-20 13:26       ` Baoquan He
2017-04-24 20:37       ` Thomas Garnier
2017-04-24 20:37         ` Thomas Garnier
2017-04-24 20:52         ` Dan Williams
2017-04-24 20:52           ` Dan Williams
2017-04-24 23:07           ` Baoquan He
2017-04-24 23:07             ` Baoquan He
2017-04-24 23:18             ` Dan Williams
2017-04-24 23:18               ` Dan Williams
2017-04-24 23:56               ` Baoquan He [this message]
2017-04-24 23:56                 ` Baoquan He
2017-04-25  0:41             ` Thomas Garnier
2017-04-25  0:41               ` Thomas Garnier
2017-04-25  1:18               ` Baoquan He
2017-04-25  1:18                 ` Baoquan He
2017-05-01 11:32 ` 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=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.