Re: Crash in -next due to 'mm/vmalloc: replace opencoded 4-level page walkers'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Date: Mon, 9 Jan 2017 11:37:07 +0000

> Could some mm expert explain why it is safe for mm/vmalloc.c to ignore
> huge pud/pmd that raise BUG_ON in the same code in mm/memory.c
> (vmap_pmd_range() vs apply_to_pmd_range())?
> 
> At a guess, is sparc64 covering the init_mm with a huge zero page? How
> is it then meant to be split? Something like

We map the linear physical area (PAGE_OFFSET --> PAGE_OFFSET +
max_phys_addr) using huge pages unless DEBUG_PAGEALLOC is enabled.

It is not meant to be split, and that's why we don't use huge pages
when DEBUG_PAGEALLOC is set since that requires changes to the mapping
to be possible.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux