Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 14 Sep 2022 10:32:00 +0100
From:   Mike Rapoport <rppt@kernel.org>
To:     Christophe Leroy <christophe.leroy@csgroup.eu>
Cc:     Pali =?iso-8859-1?Q?Roh=E1r?= <pali@kernel.org>,
        Ash Logan <ash@heyquark.com>,
        "paulus@samba.org" <paulus@samba.org>,
        "mpe@ellerman.id.au" <mpe@ellerman.id.au>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "benh@kernel.crashing.org" <benh@kernel.crashing.org>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "j.ne@posteo.net" <j.ne@posteo.net>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Fragmented physical memory on powerpc/32
Message-ID: <YyGfkDKgeW7/nNlr@kernel.org>
References: <20220609222420.ponpoodiqmaqtwht@pali>
 <20220808184034.lskqrk6z3gb5q76r@pali>
 <219cda7b-da4b-7a5a-9809-0878e0fc02ba@csgroup.eu>
 <20220908153511.57ceunyusziqfcav@pali>
 <20220908201701.sd3zqn5hfixmjvhh@pali>
 <9fbc5338-5e10-032a-8f55-e080bd93f74b@csgroup.eu>
 <Yx9GpV1XT8r2a++R@kernel.org>
 <20220912211623.djb7fckgknyfmof7@pali>
 <1c95875c-29f8-68b7-e480-fed8614f3037@csgroup.eu>
 <4f540391-37dc-8e22-be0a-74543082504d@csgroup.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4f540391-37dc-8e22-be0a-74543082504d@csgroup.eu>
Precedence: bulk

On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote:
> 
> 
> Le 13/09/2022 ? 08:11, Christophe Leroy a ?crit?:
> > 
> > 
> > Le 12/09/2022 ? 23:16, Pali Roh?r a ?crit?:
> > > > 
> > > > My guess would be that something went wrong in the linear map
> > > > setup, but it
> > > > won't hurt running with "memblock=debug" added to the kernel
> > > > command line
> > > > to see if there is anything suspicious there.
> > > 
> > > Here is boot log on serial console with memblock=debug command line:
> > > 
> > ...
> > > 
> > > Do you need something more for debug?
> > 
> > Can you send me the 'vmlinux' used to generate the above Oops so that I
> > can see exactly where we are in function mem_init().
> > 
> > And could you also try without CONFIG_HIGHMEM just in case.
> > 
> 
> I looked at the vmlinux you sent me, the problem is in the loop for highmem
> in mem_init(). It crashes in the call to free_highmem_page()
> 
> #ifdef CONFIG_HIGHMEM
> 	{
> 		unsigned long pfn, highmem_mapnr;
> 
> 		highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT;
> 		for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
> 			phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT;
> 			struct page *page = pfn_to_page(pfn);
> 			if (!memblock_is_reserved(paddr))
> 				free_highmem_page(page);
> 		}
> 	}
> #endif /* CONFIG_HIGHMEM */
> 
> 
> As far as I can see in the memblock debug lines, the holes don't seem to be
> marked as reserved by memblock. So it is above valid ? Other architectures
> seem to do differently.
> 
> Can you try by replacing !memblock_is_reserved(paddr) by
> memblock_is_memory(paddr) ?

The holes should not be marked as reserved, we just need to loop over the
memory ranges rather than over pfns. Then the holes will be taken into
account.

I believe arm and xtensa got this right:

(from arch/arm/mm/init.c)

static void __init free_highpages(void)
{
#ifdef CONFIG_HIGHMEM
	unsigned long max_low = max_low_pfn;
	phys_addr_t range_start, range_end;
	u64 i;

	/* set highmem page free */
	for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
				&range_start, &range_end, NULL) {
		unsigned long start = PFN_UP(range_start);
		unsigned long end = PFN_DOWN(range_end);

		/* Ignore complete lowmem entries */
		if (end <= max_low)
			continue;

		/* Truncate partial highmem entries */
		if (start < max_low)
			start = max_low;

		for (; start < end; start++)
			free_highmem_page(pfn_to_page(start));
	}
#endif
}

 
> Thanks
> Christophe
> 

-- 
Sincerely yours,
Mike.