Arm64 crash while reading memory sysfs

Mike Rapoport rppt at linux.ibm.com
Wed May 26 10:25:04 PDT 2021


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
pfn_valid().

-- 
Sincerely yours,
Mike.



More information about the linux-arm-kernel mailing list