From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-xtensa@linux-xtensa.org,
Florian Fainelli <f.fainelli@gmail.com>,
Chris Zankel <chris@zankel.net>,
Linus Walleij <linus.walleij@linaro.org>,
linux-kernel@vger.kernel.org, Mike Rapoport <rppt@linux.ibm.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM, xtensa: highmem: avoid clobbering non-page aligned memory reservations
Date: Sat, 31 Oct 2020 10:33:12 +0000 [thread overview]
Message-ID: <20201031103312.GI1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20201031094345.6984-1-rppt@kernel.org>
On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> free_highpages() iterates over the free memblock regions in high
> memory, and marks each page as available for the memory management
> system.
>
> Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> high memory pages") it rounded beginning of each region upwards and end of
> each region downwards.
>
> However, after that commit free_highmem() rounds the beginning and end of
> each region downwards, and we may end up freeing a page that is
> memblock_reserve()d, resulting in memory corruption.
>
> Restore the original rounding of the region boundaries to avoid freeing
> reserved pages.
>
> Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> Link: https://lore.kernel.org/r/20201029110334.4118-1-ardb@kernel.org/
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> Co-developed-by: Mike Rapoport <rppt@linux.ibm.com>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>
> Max, Russell,
>
> Please let me know how do you prefer to take it upstream.
> If needed this can go via memblock tree.
>
> v2: fix words order in the commit message
I really don't understand what is going on here; there seems to be a
total disconnect of communication between yourself and Ard. Ard has
already submitted a different patch for this to the patch system
already, sent yesterday.
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
Please discuss between yourselves how you want to solve the problem,
and then submit an agreed and tested patch to those of us upstream;
please don't make it for those upstream to pick one of your patches
as you are at present.
Thanks.
>
> arch/arm/mm/init.c | 4 ++--
> arch/xtensa/mm/init.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index d57112a276f5..c23dbf8bebee 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -354,8 +354,8 @@ static void __init free_highpages(void)
> /* set highmem page free */
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> &range_start, &range_end, NULL) {
> - unsigned long start = PHYS_PFN(range_start);
> - unsigned long end = PHYS_PFN(range_end);
> + unsigned long start = PFN_UP(range_start);
> + unsigned long end = PFN_DOWN(range_end);
>
> /* Ignore complete lowmem entries */
> if (end <= max_low)
> diff --git a/arch/xtensa/mm/init.c b/arch/xtensa/mm/init.c
> index c6fc83efee0c..8731b7ad9308 100644
> --- a/arch/xtensa/mm/init.c
> +++ b/arch/xtensa/mm/init.c
> @@ -89,8 +89,8 @@ static void __init free_highpages(void)
> /* set highmem page free */
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> &range_start, &range_end, NULL) {
> - unsigned long start = PHYS_PFN(range_start);
> - unsigned long end = PHYS_PFN(range_end);
> + unsigned long start = PFN_UP(range_start);
> + unsigned long end = PFN_DOWN(range_end);
>
> /* Ignore complete lowmem entries */
> if (end <= max_low)
> --
> 2.28.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-xtensa@linux-xtensa.org, Ard Biesheuvel <ardb@kernel.org>,
Chris Zankel <chris@zankel.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Max Filippov <jcmvbkbc@gmail.com>,
Mike Rapoport <rppt@linux.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM, xtensa: highmem: avoid clobbering non-page aligned memory reservations
Date: Sat, 31 Oct 2020 10:33:12 +0000 [thread overview]
Message-ID: <20201031103312.GI1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20201031094345.6984-1-rppt@kernel.org>
On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> free_highpages() iterates over the free memblock regions in high
> memory, and marks each page as available for the memory management
> system.
>
> Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> high memory pages") it rounded beginning of each region upwards and end of
> each region downwards.
>
> However, after that commit free_highmem() rounds the beginning and end of
> each region downwards, and we may end up freeing a page that is
> memblock_reserve()d, resulting in memory corruption.
>
> Restore the original rounding of the region boundaries to avoid freeing
> reserved pages.
>
> Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> Link: https://lore.kernel.org/r/20201029110334.4118-1-ardb@kernel.org/
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> Co-developed-by: Mike Rapoport <rppt@linux.ibm.com>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>
> Max, Russell,
>
> Please let me know how do you prefer to take it upstream.
> If needed this can go via memblock tree.
>
> v2: fix words order in the commit message
I really don't understand what is going on here; there seems to be a
total disconnect of communication between yourself and Ard. Ard has
already submitted a different patch for this to the patch system
already, sent yesterday.
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
Please discuss between yourselves how you want to solve the problem,
and then submit an agreed and tested patch to those of us upstream;
please don't make it for those upstream to pick one of your patches
as you are at present.
Thanks.
>
> arch/arm/mm/init.c | 4 ++--
> arch/xtensa/mm/init.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index d57112a276f5..c23dbf8bebee 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -354,8 +354,8 @@ static void __init free_highpages(void)
> /* set highmem page free */
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> &range_start, &range_end, NULL) {
> - unsigned long start = PHYS_PFN(range_start);
> - unsigned long end = PHYS_PFN(range_end);
> + unsigned long start = PFN_UP(range_start);
> + unsigned long end = PFN_DOWN(range_end);
>
> /* Ignore complete lowmem entries */
> if (end <= max_low)
> diff --git a/arch/xtensa/mm/init.c b/arch/xtensa/mm/init.c
> index c6fc83efee0c..8731b7ad9308 100644
> --- a/arch/xtensa/mm/init.c
> +++ b/arch/xtensa/mm/init.c
> @@ -89,8 +89,8 @@ static void __init free_highpages(void)
> /* set highmem page free */
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> &range_start, &range_end, NULL) {
> - unsigned long start = PHYS_PFN(range_start);
> - unsigned long end = PHYS_PFN(range_end);
> + unsigned long start = PFN_UP(range_start);
> + unsigned long end = PFN_DOWN(range_end);
>
> /* Ignore complete lowmem entries */
> if (end <= max_low)
> --
> 2.28.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2020-10-31 10:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 9:43 [PATCH] ARM, xtensa: highmem: avoid clobbering non-page aligned memory reservations Mike Rapoport
2020-10-31 9:43 ` Mike Rapoport
2020-10-31 10:33 ` Russell King - ARM Linux admin [this message]
2020-10-31 10:33 ` Russell King - ARM Linux admin
2020-10-31 10:47 ` Ard Biesheuvel
2020-10-31 10:47 ` Ard Biesheuvel
2020-10-31 11:03 ` Russell King - ARM Linux admin
2020-10-31 11:03 ` Russell King - ARM Linux admin
2020-10-31 11:21 ` Ard Biesheuvel
2020-10-31 11:21 ` Ard Biesheuvel
2020-10-31 15:45 ` Mike Rapoport
2020-10-31 15:45 ` Mike Rapoport
2020-11-04 8:51 ` Mike Rapoport
2020-11-04 8:51 ` Mike Rapoport
2020-10-31 16:37 ` Max Filippov
2020-10-31 16:37 ` Max Filippov
2020-10-31 17:16 ` Mike Rapoport
2020-10-31 17:16 ` Mike Rapoport
2020-10-31 17:44 ` Max Filippov
2020-10-31 17:44 ` Max Filippov
2020-11-04 8:35 ` Ard Biesheuvel
2020-11-04 8:35 ` Ard Biesheuvel
2020-11-04 8:49 ` Mike Rapoport
2020-11-04 8:49 ` 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=20201031103312.GI1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=ardb@kernel.org \
--cc=chris@zankel.net \
--cc=f.fainelli@gmail.com \
--cc=jcmvbkbc@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
/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.