Re: Arm64 crash while reading memory sysfs
From: Mike Rapoport
Date: Wed May 26 2021 - 13:25:24 EST
On Wed, May 26, 2021 at 02:04:26PM +0100, Catalin Marinas wrote:
> On Wed, May 26, 2021 at 12:09:14PM +0000, Qian Cai (QUIC) wrote:
> > [ 0.000000] Early memory node ranges
> > [ 0.000000] node 0: [mem 0x0000000090000000-0x0000000091ffffff]
> Maybe de-selecting HOLES_IN_ZONE is not correct for arm64 in all
> circumstances. In a configuration with 64K pages, MAX_ORDER is 14,
> MAX_ORDER_NR_PAGES is 8192, so a 2^29 address range. However, the above
> range starts on 2^28 boundary.
> SECTION_SIZE_BITS is 29 in this configuration but the corresponding
> mem_map in the first half of the first section is probably not marked
> as reserved as we'd do for NOMAP.
We do initialize (or at least we should) the first of the first section in
page_alloc::init_unavailable_range() so the range [0x8000000 - 0x9000000]
will have struct pages marked as reserved.
I think it should be fine to de-select HOLES_IN_ZONE as long as MAX_ORDER
chunk does not exceed a section because we do have memory map there in such
case and HOLES_IN_ZONE along with pfn_valid_within() protected against
access to non-existing memory map entries.
We still have an issue with memory map initialization, and probably I've
missed something in decoupling of "do we have memory there" from