All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	liulhong617 <liulhong617@gmail.com>
Subject: Re: [PATCH] arm64: mm: Fix pfn_is_map_memory() misreporting mapped memory
Date: Thu, 17 Sep 2026 12:42:41 +0300	[thread overview]
Message-ID: <aqu2EReSAxYG_8sb@kernel.org> (raw)
In-Reply-To: <947a1506-dfe4-4906-9673-6a7227946433@app.fastmail.com>

On Wed, Sep 16, 2026 at 12:13:21PM +0200, Ard Biesheuvel wrote:
> (cc Mike)
> 
> On Tue, 8 Sep 2026, at 18:20, Vladimir Murzin wrote:
> > Commit 7ace06a01efa ("arm64: mm: fix accidental linear mapping of
> > no-map reserved memory") removed sub-page no-map regions from the
> > linear mapping. However, pfn_is_map_memory() can still report that
> > such a region is mapped.
> >
> > For instance, with 64K pages, say we have
> >
> > normal:        ...–0xa2007fff
> > no-map: 0xa2008000–0xa200ffff
> > normal: 0xa2010000–...
> >
> > The range 0xa2000000–0xa200ffff is not linearly mapped, but
> > pfn_is_map_memory(__phys_to_pfn(0xa2008000)) aligns the address to
> > page granularity and passes 0xa2000000 to memblock_is_map_memory().
> > That address belongs to the preceding normal memblock region, so the
> > no-map region is ignored and the function returns true.
> >
> > Fix that by checking if entire page is subset of memory block.
> >
> > Fixes: 7ace06a01efa ("arm64: mm: fix accidental linear mapping of 
> > no-map reserved memory")
> > Assisted-by: LLM
> > Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> > ---
> >  arch/arm64/mm/init.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index fbf215ecc7d0..5da80e1e1727 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -172,7 +172,8 @@ int pfn_is_map_memory(unsigned long pfn)
> >  	if (PHYS_PFN(addr) != pfn)
> >  		return 0;
> > 
> > -	return memblock_is_map_memory(addr);
> > +	return memblock_is_region_memory(addr, PAGE_SIZE) &&
> > +		memblock_is_map_memory(addr);
> >  }
> >  EXPORT_SYMBOL(pfn_is_map_memory);
> > 
> 
> memblock_is_region_memory() only tells you whether the range in
> question is covered by a single entry in memblock.memory.regions[].
> 
> memblock has other flags, which may or may not be set on sub-page
> regions too. So I don't think this is the right solution in the
> general case, even if it fixes your example.
> 
> Given that the no-map attribute fundamentally only applies to page
> granular regions, it would make sense to round those outwards
> whenever they are created.
> 
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1119,6 +1119,10 @@
>  int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
>  {
> +       phys_addr_t end = PAGE_ALIGN(base + size);
> +
> +       base &= PAGE_MASK;
> +       size = end - base;
>         return memblock_setclr_flag(&memblock.memory, base, size, 1, MEMBLOCK_NOMAP);
>  }

Makes sense to me, just lacks kernel-doc update ;-)

> Note that I recently removed the frivolous use of MEMBLOCK_NOMAP in
> __map_mem() so the remaining calls should mostly be true reservations
> originating from the boot environment.

There is still riscv :)

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2026-09-17  9:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 16:20 [PATCH] arm64: mm: Fix pfn_is_map_memory() misreporting mapped memory Vladimir Murzin
2026-09-09 13:31 ` Will Deacon
2026-09-10 13:57   ` Vladimir Murzin
2026-09-11 12:35     ` Will Deacon
2026-09-16 10:13 ` Ard Biesheuvel
2026-09-17  9:42   ` Mike Rapoport [this message]
2026-09-17 12:26   ` Vladimir Murzin
2026-09-17 12:34     ` Ard Biesheuvel
2026-09-17 13:13       ` Mike Rapoport
2026-09-17 14:29       ` Mike Rapoport
2026-09-17 15:17         ` Ard Biesheuvel
2026-09-22  5:50           ` Mike Rapoport
2026-09-24 10:59             ` Ard Biesheuvel
2026-09-24 17:06               ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aqu2EReSAxYG_8sb@kernel.org \
    --to=rppt@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=liulhong617@gmail.com \
    --cc=vladimir.murzin@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.