linux-kernel - Re: Fragmented physical memory on powerpc/32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Sep 2022 14:36:13 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Pali Rohár <pali@...nel.org>,
        Mike Rapoport <rppt@...nel.org>
Cc:     Ash Logan <ash@...quark.com>,
        "paulus@...ba.org" <paulus@...ba.org>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "j.ne@...teo.net" <j.ne@...teo.net>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: Fragmented physical memory on powerpc/32



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) ?

Thanks
Christophe