Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 May 2021 20:25:04 +0300
From:   Mike Rapoport <rppt@linux.ibm.com>
To:     Catalin Marinas <catalin.marinas@arm.com>
Cc:     "Qian Cai (QUIC)" <quic_qiancai@quicinc.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Hildenbrand <david@redhat.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Arm64 crash while reading memory sysfs
Message-ID: <YK6EcMPETjBkVahC@linux.ibm.com>
References: <DM5PR0201MB355723819DDAC439273F68848E259@DM5PR0201MB3557.namprd02.prod.outlook.com>
 <YK3tQ0a0S/CLxyyb@linux.ibm.com>
 <CY4PR0201MB35539FF5EE729283C4241F5A8E249@CY4PR0201MB3553.namprd02.prod.outlook.com>
 <20210526130426.GD19992@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210526130426.GD19992@arm.com>
Precedence: bulk

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.