[PATCH] arm64: Use correct method to calculate nomap region boundaries

[Huacai Chen]

Hi, Will,

On Tue, Dec 14, 2021 at 10:11 PM Will Deacon <will at kernel.org> wrote:
>
> On Tue, Dec 14, 2021 at 08:50:14AM +0800, Huacai Chen wrote:
> > Hi, Will,
> >
> > On Tue, Dec 14, 2021 at 3:07 AM Will Deacon <will at kernel.org> wrote:
> > >
> > > On Mon, Dec 06, 2021 at 12:46:27PM +0800, Huacai Chen wrote:
> > > > On Thu, Dec 2, 2021 at 6:08 PM Will Deacon <will at kernel.org> wrote:
> > > > > On Fri, Oct 22, 2021 at 03:06:46PM +0800, Huacai Chen wrote:
> > > > > > Nomap regions are treated as "reserved". When region boundaries are not
> > > > > > page aligned, we usually increase the "reserved" regions rather than
> > > > > > decrease them. So, we should use memblock_region_reserved_base_pfn()/
> > > > > > memblock_region_reserved_end_pfn() instead of memblock_region_memory_
> > > > > > base_pfn()/memblock_region_memory_base_pfn() to calculate boundaries.
> > > > > >
> > > > > > Signed-off-by: Huacai Chen <chenhuacai at loongson.cn>
> > > > > > ---
> > > > > >  arch/arm64/kernel/setup.c | 6 ++++--
> > > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > > > > index be5f85b0a24d..1e86d4c5ef8c 100644
> > > > > > --- a/arch/arm64/kernel/setup.c
> > > > > > +++ b/arch/arm64/kernel/setup.c
> > > > > > @@ -232,12 +232,14 @@ static void __init request_standard_resources(void)
> > > > > >               if (memblock_is_nomap(region)) {
> > > > > >                       res->name  = "reserved";
> > > > > >                       res->flags = IORESOURCE_MEM;
> > > > > > +                     res->start = __pfn_to_phys(memblock_region_reserved_base_pfn(region));
> > > > > > +                     res->end = __pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1;
> > > > > >               } else {
> > > > > >                       res->name  = "System RAM";
> > > > > >                       res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> > > > > > +                     res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> > > > > > +                     res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
> > > > > >               }
> > > > > > -             res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> > > > > > -             res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
> > > > >
> > > > > Under which circumstances would the nomap regions not be page-aligned? That
> > > > > sounds like something we should prevent, rather than work around here.
> > > >
> > > > In this call path:
> > > > acpi_table_upgrade --> arch_reserve_mem_area --> memblock_mark_nomap
> > > > The nomap region is not page-aligned.
> > >
> > > Fair enough, then I think this patch is probably doing the right thing.
> > > However, Ard and Mark had some concerns about the new behaviour wrt
> > > adjacent nomap regions where the page containing the overlap would be
> > > reported twice. Is this a problem?
> > Seems no problem,  in most cases, memblock_mark_nomap() -->
> > memblock_merge_regions() --> memblock_merge_regions(), adjacent
> > intesected regions will be merged. Then the only problem is two or
> > more small regions not intersected but in a single page, I think this
> > is hardly happen..
>
> What happens _today_ if we run into that case? Does end get rounded down
> below start?
Yes, the "end" will be below "start", and the small regions disappear
in /proc/iomem.

Huacai
>
> Will