From: Catalin Marinas <catalin.marinas@arm.com>
To: Ross Stutterheim <ross.stutterheim@garmin.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, ross.sweng@gmail.com,
Mike Rapoport <rppt@kernel.org>,
Russell King <linux@armlinux.org.uk>
Subject: Re: [PATCH] arm[64]/memremap: fix arch_memremap_can_ram_remap()
Date: Mon, 14 Apr 2025 14:49:50 +0100 [thread overview]
Message-ID: <Z_0SfqQHsKs3S1cn@arm.com> (raw)
In-Reply-To: <20250414133219.107455-1-ross.stutterheim@garmin.com>
Please cc the maintainers and the original contributor of the commit you
are fixing, otherwise the patch may not be noticed.
On Mon, Apr 14, 2025 at 08:32:19AM -0500, Ross Stutterheim wrote:
> commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure
> presence of linear map") added the definition of
> arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages
> can be used from the linear mapping. memblock_is_map_memory() was called
> with the pfn of the address given to arch_memremap_can_ram_remap();
> however, memblock_is_map_memory() expects to be given an address, not a
> pfn.
>
> This results in calls to memremap() returning a newly mapped area when
> it should return an address in the existing linear mapping.
>
> Fix this by removing the address to pfn translation and pass the
> address directly.
>
> Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map")
> Signed-off-by: Ross Stutterheim <ross.stutterheim@garmin.com>
> ---
> arch/arm/mm/ioremap.c | 4 +---
> arch/arm64/mm/ioremap.c | 4 +---
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 748698e91a4b..27e64f782cb3 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -515,7 +515,5 @@ void __init early_ioremap_init(void)
> bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> unsigned long flags)
> {
> - unsigned long pfn = PHYS_PFN(offset);
> -
> - return memblock_is_map_memory(pfn);
> + return memblock_is_map_memory(offset);
> }
This indeed needs fixing.
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index 10e246f11271..48c38c986b95 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -51,7 +51,5 @@ void __init early_ioremap_init(void)
> bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> unsigned long flags)
> {
> - unsigned long pfn = PHYS_PFN(offset);
> -
> - return pfn_is_map_memory(pfn);
> + return pfn_is_map_memory(offset);
This is already correct.
--
Catalin
next prev parent reply other threads:[~2025-04-14 13:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 13:32 [PATCH] arm[64]/memremap: fix arch_memremap_can_ram_remap() Ross Stutterheim
2025-04-14 13:49 ` Catalin Marinas [this message]
2025-04-14 14:18 ` Ross Stutterheim
2025-04-14 14:21 ` [PATCH v2] arm/memremap: " Ross Stutterheim
2025-04-16 10:09 ` Catalin Marinas
2025-04-16 13:57 ` Ross Stutterheim
2025-04-16 15:48 ` Russell King (Oracle)
2025-04-16 22:54 ` Catalin Marinas
2025-04-19 7:04 ` Mike Rapoport
2025-04-16 11:13 ` Linus Walleij
2025-04-16 13:52 ` [PATCH v3] " Ross Stutterheim
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=Z_0SfqQHsKs3S1cn@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=ross.stutterheim@garmin.com \
--cc=ross.sweng@gmail.com \
--cc=rppt@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.