From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F1E5C21954086 for ; Mon, 24 Apr 2017 16:56:24 -0700 (PDT) Date: Tue, 25 Apr 2017 07:56:20 +0800 From: Baoquan He Subject: Re: KASLR causes intermittent boot failures on some systems Message-ID: <20170424235620.GB11734@x1> References: <20170419133630.GA2311@x1> <20170420132632.GD2311@x1> <20170424230738.GA11734@x1> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: LKML , "linux-nvdimm@lists.01.org" , Thomas Garnier , Ingo Molnar List-ID: On 04/24/17 at 04:18pm, Dan Williams wrote: > On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S979410AbdDXX4c (ORCPT ); Mon, 24 Apr 2017 19:56:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50372 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S977979AbdDXX4Y (ORCPT ); Mon, 24 Apr 2017 19:56:24 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5167B6330D Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bhe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5167B6330D Date: Tue, 25 Apr 2017 07:56:20 +0800 From: Baoquan He To: Dan Williams Cc: Thomas Garnier , Jeff Moyer , Ingo Molnar , LKML , "linux-nvdimm@lists.01.org" Subject: Re: KASLR causes intermittent boot failures on some systems Message-ID: <20170424235620.GB11734@x1> References: <20170419133630.GA2311@x1> <20170420132632.GD2311@x1> <20170424230738.GA11734@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 24 Apr 2017 23:56:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/24/17 at 04:18pm, Dan Williams wrote: > On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He 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