Re: [PATCH] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map

From: Mike Rapoport
Date: Sun Apr 24 2022 - 23:58:44 EST


On Sun, Apr 24, 2022 at 11:19:05PM +0200, Ard Biesheuvel wrote:
> On Sun, 24 Apr 2022 at 19:22, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> >
> > From: Mike Rapoport <rppt@xxxxxxxxxxxxx>
> >
> > The semantics of pfn_valid() is to check presence of the memory map for a
> > PFN and not whether a PFN is covered by the linear map. The memory map may
> > be present for NOMAP memory regions, but they won't be mapped in the linear
> > mapping. Accessing such regions via __va() when they are memremap()'ed
> > will cause a crash.

...

> > diff --git a/kernel/iomem.c b/kernel/iomem.c
> > index 62c92e43aa0d..e85bed24c0a9 100644
> > --- a/kernel/iomem.c
> > +++ b/kernel/iomem.c
> > @@ -33,7 +33,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
> > unsigned long pfn = PHYS_PFN(offset);
> >
> > /* In the simple case just return the existing linear address */
> > - if (pfn_valid(pfn) && !PageHighMem(pfn_to_page(pfn)) &&
> > + if (!PageHighMem(pfn_to_page(pfn)) &&
>
> This looks wrong to me. Calling any of the PageXxx() accessors is only
> safe if the PFN is valid, since otherwise, we don't know if the
> associated struct page exists.

Yeah, you are right, was over-enthusiastic here...

> > arch_memremap_can_ram_remap(offset, size, flags))
> > return __va(offset);
> >
> >
> > base-commit: b2d229d4ddb17db541098b83524d901257e93845
> > --
> > 2.28.0
> >

--
Sincerely yours,
Mike.