All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michal Simek <monstr@monstr.eu>,
	Mike Rapoport <rppt@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/4] mm/page_alloc: always initialize memory map for the holes
Date: Sat, 31 Jul 2021 12:11:16 -0700	[thread overview]
Message-ID: <f6ec888c-91ee-de4e-45c8-58133c5ffeb4@roeck-us.net> (raw)
In-Reply-To: <YQWW3RCE4eWBuMu/@kernel.org>

Hi,

On 7/31/21 11:30 AM, Mike Rapoport wrote:
> On Sat, Jul 31, 2021 at 09:56:01AM -0700, Guenter Roeck wrote:
>> Hi,
>>
>> On Wed, Jul 14, 2021 at 03:37:36PM +0300, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> Currently memory map for the holes is initialized only when SPARSEMEM
>>> memory model is used. Yet, even with FLATMEM there could be holes in the
>>> physical memory layout that have memory map entries.
>>>
>>> For instance, the memory reserved using e820 API on i386 or
>>> "reserved-memory" nodes in device tree would not appear in memblock.memory
>>> and hence the struct pages for such holes will be skipped during memory map
>>> initialization.
>>>
>>> These struct pages will be zeroed because the memory map for FLATMEM
>>> systems is allocated with memblock_alloc_node() that clears the allocated
>>> memory. While zeroed struct pages do not cause immediate problems, the
>>> correct behaviour is to initialize every page using __init_single_page().
>>> Besides, enabling page poison for FLATMEM case will trigger
>>> PF_POISONED_CHECK() unless the memory map is properly initialized.
>>>
>>> Make sure init_unavailable_range() is called for both SPARSEMEM and FLATMEM
>>> so that struct pages representing memory holes would appear as PG_Reserved
>>> with any memory layout.
>>>
>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>>
>> This patch causes microblaze petalogix-ml605 qemu emulations to fail
>> silently (no console output). Reverting it fixes the problem.
> 
> It appears that petalogix-ml605 memory starts at 0x50000, but microblaze's
> pfn_valid does not reject pfns < ARCH_PFN_OFFSET.
> 
> This should fix the issue:
> 
> diff --git a/arch/microblaze/include/asm/page.h b/arch/microblaze/include/asm/page.h
> index ce550978f4fc..4b8b2fa78fc5 100644
> --- a/arch/microblaze/include/asm/page.h
> +++ b/arch/microblaze/include/asm/page.h
> @@ -112,8 +112,7 @@ extern int page_is_ram(unsigned long pfn);
>   #  define page_to_phys(page)     (page_to_pfn(page) << PAGE_SHIFT)
>   
>   #  define ARCH_PFN_OFFSET	(memory_start >> PAGE_SHIFT)
> -#  define pfn_valid(pfn)	((pfn) < (max_mapnr + ARCH_PFN_OFFSET))
> -
> +#  define pfn_valid(pfn)	((pfn) >= ARCH_PFN_OFFSET && (pfn) < (max_mapnr + ARCH_PFN_OFFSET))
>   # endif /* __ASSEMBLY__ */
>   
>   #define	virt_addr_valid(vaddr)	(pfn_valid(virt_to_pfn(vaddr)))

Indeed, that does the trick.

Feel free to add

Tested-by: Guenter Roeck <linux@roeck-us.net>

to the patch.

Thanks,
Guenter

>> Guenter
>>
>> ---
>> Bisect log:
>>
>> # bad: [8d4b477da1a807199ca60e0829357ce7aa6758d5] Add linux-next specific files for 20210730
>> # good: [ff1176468d368232b684f75e82563369208bc371] Linux 5.14-rc3
>> git bisect start 'HEAD' 'v5.14-rc3'
>> # good: [8f3eb1f5c702ef868d89799b03c21d122f2fe197] Merge remote-tracking branch 'bpf-next/for-next'
>> git bisect good 8f3eb1f5c702ef868d89799b03c21d122f2fe197
>> # good: [32286c7080c56c835f25302c38eebccf41b7b576] Merge remote-tracking branch 'tip/auto-latest'
>> git bisect good 32286c7080c56c835f25302c38eebccf41b7b576
>> # good: [70c40604c7d393f95171f49717a27bf8e05b5439] Merge remote-tracking branch 'dmaengine/next'
>> git bisect good 70c40604c7d393f95171f49717a27bf8e05b5439
>> # good: [b038834891b35ec410693028a500f769db132a81] Merge remote-tracking branch 'rust/rust-next'
>> git bisect good b038834891b35ec410693028a500f769db132a81
>> # bad: [d8f4e506a9ba375110945d75573b3304491e6350] memory-hotplug.rst: complete admin-guide overhaul
>> git bisect bad d8f4e506a9ba375110945d75573b3304491e6350
>> # good: [bef692dcfb7cdb5c960abfc31e2386a0ff41af54] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
>> git bisect good bef692dcfb7cdb5c960abfc31e2386a0ff41af54
>> # bad: [5fcd957e2f0dc4cb25a6ee60ebfb1200de09c9d1] mm-migrate-demote-pages-during-reclaim-v11
>> git bisect bad 5fcd957e2f0dc4cb25a6ee60ebfb1200de09c9d1
>> # good: [8c2a82ab20eb09d217446989ae209f5ff19a64ac] mm/vmalloc: use batched page requests in bulk-allocator
>> git bisect good 8c2a82ab20eb09d217446989ae209f5ff19a64ac
>> # bad: [c36a5446e29f1461780b06785769b9402522f847] mm/page_alloc.c: fix 'zone_id' may be used uninitialized in this function warning
>> git bisect bad c36a5446e29f1461780b06785769b9402522f847
>> # good: [05e358c552628e26be3985933bea88e7512414c0] mm/kasan: move kasan.fault to mm/kasan/report.c
>> git bisect good 05e358c552628e26be3985933bea88e7512414c0
>> # bad: [b467ff7f560908e60ca181658b7ee48e5da94da1] microblaze: simplify pte_alloc_one_kernel()
>> git bisect bad b467ff7f560908e60ca181658b7ee48e5da94da1
>> # bad: [d2a572bf593a57246827bd79c91fe2ee6b7af1f0] mm/page_alloc: always initialize memory map for the holes
>> git bisect bad d2a572bf593a57246827bd79c91fe2ee6b7af1f0
>> # first bad commit: [d2a572bf593a57246827bd79c91fe2ee6b7af1f0] mm/page_alloc: always initialize memory map for the holes
> 


  reply	other threads:[~2021-07-31 19:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 12:37 [PATCH 0/4] mm: ensure consistency of memory map poisoning Mike Rapoport
2021-07-14 12:37 ` [PATCH 1/4] mm/page_alloc: always initialize memory map for the holes Mike Rapoport
2021-07-31 16:56   ` Guenter Roeck
2021-07-31 18:30     ` Mike Rapoport
2021-07-31 19:11       ` Guenter Roeck [this message]
2021-08-25 12:11   ` David Hildenbrand
2021-07-14 12:37 ` [PATCH 2/4] microblaze: simplify pte_alloc_one_kernel() Mike Rapoport
2021-08-25 10:09   ` Michal Simek
2021-08-25 12:13   ` David Hildenbrand
2021-07-14 12:37 ` [PATCH 3/4] mm: introduce memmap_alloc() to unify memory map allocation Mike Rapoport
2021-07-14 22:32   ` Andrew Morton
2021-07-15  6:10     ` Mike Rapoport
2021-07-14 12:37 ` [PATCH 4/4] memblock: stop poisoning raw allocations Mike Rapoport
2021-07-31 17:13   ` Joe Perches
2021-07-31 17:13     ` Joe Perches
2021-08-03  7:58     ` Mike Rapoport
2021-08-03 16:19       ` Joe Perches
2021-08-03 16:19         ` Joe Perches

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=f6ec888c-91ee-de4e-45c8-58133c5ffeb4@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=monstr@monstr.eu \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.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.