Messages in this thread | | | Date | Mon, 25 Apr 2022 06:58:08 +0300 | From | Mike Rapoport <> | Subject | Re: [PATCH] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map |
| |
On Sun, Apr 24, 2022 at 11:19:05PM +0200, Ard Biesheuvel wrote: > On Sun, 24 Apr 2022 at 19:22, Mike Rapoport <rppt@kernel.org> wrote: > > > > From: Mike Rapoport <rppt@linux.ibm.com> > > > > 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.
| |