From: Catalin Marinas <catalin.marinas@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "alex@ghiti.fr" <alex@ghiti.fr>,
Steve Capper <steve.capper@arm.com>,
Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"will@kernel.org" <will@kernel.org>,
Paul Mackerras <paulus@samba.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v6 04/14] mm, hugetlbfs: Allow for "high" userspace addresses
Date: Tue, 4 Jan 2022 16:21:36 +0000 [thread overview]
Message-ID: <YdR0EN2mdJuysugk@arm.com> (raw)
In-Reply-To: <db238c1ca2d46e33c57328f8d450f2563e92f8c2.1639736449.git.christophe.leroy@csgroup.eu>
On Fri, Dec 17, 2021 at 10:27:28AM +0000, Christophe Leroy wrote:
> This is a complement of f6795053dac8 ("mm: mmap: Allow for "high"
> userspace addresses") for hugetlb.
>
> This patch adds support for "high" userspace addresses that are
> optionally supported on the system and have to be requested via a hint
> mechanism ("high" addr parameter to mmap).
>
> Architectures such as powerpc and x86 achieve this by making changes to
> their architectural versions of hugetlb_get_unmapped_area() function.
> However, arm64 uses the generic version of that function.
>
> So take into account arch_get_mmap_base() and arch_get_mmap_end() in
> hugetlb_get_unmapped_area(). To allow that, move those two macros
> out of mm/mmap.c into include/linux/sched/mm.h
>
> If these macros are not defined in architectural code then they default
> to (TASK_SIZE) and (base) so should not introduce any behavioural
> changes to architectures that do not define them.
>
> For the time being, only ARM64 is affected by this change.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> fs/hugetlbfs/inode.c | 9 +++++----
> include/linux/sched/mm.h | 8 ++++++++
> mm/mmap.c | 8 --------
> 3 files changed, 13 insertions(+), 12 deletions(-)
This would be an ABI change but I'm fine with it. Basically with this
patch, getting hugetblfs addresses above 48-bit require explicit hint
passed to mmap().
I wonder whether we should add a fixes tag (or at least the cc stable):
Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses")
Cc: <stable@vger.kernel.org> # 5.0.x
I think the original commit should have changed
hugetlb_get_unmapped_area() to have the same behaviour as
arch_get_unmapped_area(). Steve, any thoughts?
FWIW,
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"alex@ghiti.fr" <alex@ghiti.fr>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"will@kernel.org" <will@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Steve Capper <steve.capper@arm.com>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH v6 04/14] mm, hugetlbfs: Allow for "high" userspace addresses
Date: Tue, 4 Jan 2022 16:21:36 +0000 [thread overview]
Message-ID: <YdR0EN2mdJuysugk@arm.com> (raw)
In-Reply-To: <db238c1ca2d46e33c57328f8d450f2563e92f8c2.1639736449.git.christophe.leroy@csgroup.eu>
On Fri, Dec 17, 2021 at 10:27:28AM +0000, Christophe Leroy wrote:
> This is a complement of f6795053dac8 ("mm: mmap: Allow for "high"
> userspace addresses") for hugetlb.
>
> This patch adds support for "high" userspace addresses that are
> optionally supported on the system and have to be requested via a hint
> mechanism ("high" addr parameter to mmap).
>
> Architectures such as powerpc and x86 achieve this by making changes to
> their architectural versions of hugetlb_get_unmapped_area() function.
> However, arm64 uses the generic version of that function.
>
> So take into account arch_get_mmap_base() and arch_get_mmap_end() in
> hugetlb_get_unmapped_area(). To allow that, move those two macros
> out of mm/mmap.c into include/linux/sched/mm.h
>
> If these macros are not defined in architectural code then they default
> to (TASK_SIZE) and (base) so should not introduce any behavioural
> changes to architectures that do not define them.
>
> For the time being, only ARM64 is affected by this change.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> fs/hugetlbfs/inode.c | 9 +++++----
> include/linux/sched/mm.h | 8 ++++++++
> mm/mmap.c | 8 --------
> 3 files changed, 13 insertions(+), 12 deletions(-)
This would be an ABI change but I'm fine with it. Basically with this
patch, getting hugetblfs addresses above 48-bit require explicit hint
passed to mmap().
I wonder whether we should add a fixes tag (or at least the cc stable):
Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses")
Cc: <stable@vger.kernel.org> # 5.0.x
I think the original commit should have changed
hugetlb_get_unmapped_area() to have the same behaviour as
arch_get_unmapped_area(). Steve, any thoughts?
FWIW,
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
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: Catalin Marinas <catalin.marinas@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"alex@ghiti.fr" <alex@ghiti.fr>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"will@kernel.org" <will@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Steve Capper <steve.capper@arm.com>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH v6 04/14] mm, hugetlbfs: Allow for "high" userspace addresses
Date: Tue, 4 Jan 2022 16:21:36 +0000 [thread overview]
Message-ID: <YdR0EN2mdJuysugk@arm.com> (raw)
In-Reply-To: <db238c1ca2d46e33c57328f8d450f2563e92f8c2.1639736449.git.christophe.leroy@csgroup.eu>
On Fri, Dec 17, 2021 at 10:27:28AM +0000, Christophe Leroy wrote:
> This is a complement of f6795053dac8 ("mm: mmap: Allow for "high"
> userspace addresses") for hugetlb.
>
> This patch adds support for "high" userspace addresses that are
> optionally supported on the system and have to be requested via a hint
> mechanism ("high" addr parameter to mmap).
>
> Architectures such as powerpc and x86 achieve this by making changes to
> their architectural versions of hugetlb_get_unmapped_area() function.
> However, arm64 uses the generic version of that function.
>
> So take into account arch_get_mmap_base() and arch_get_mmap_end() in
> hugetlb_get_unmapped_area(). To allow that, move those two macros
> out of mm/mmap.c into include/linux/sched/mm.h
>
> If these macros are not defined in architectural code then they default
> to (TASK_SIZE) and (base) so should not introduce any behavioural
> changes to architectures that do not define them.
>
> For the time being, only ARM64 is affected by this change.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> fs/hugetlbfs/inode.c | 9 +++++----
> include/linux/sched/mm.h | 8 ++++++++
> mm/mmap.c | 8 --------
> 3 files changed, 13 insertions(+), 12 deletions(-)
This would be an ABI change but I'm fine with it. Basically with this
patch, getting hugetblfs addresses above 48-bit require explicit hint
passed to mmap().
I wonder whether we should add a fixes tag (or at least the cc stable):
Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses")
Cc: <stable@vger.kernel.org> # 5.0.x
I think the original commit should have changed
hugetlb_get_unmapped_area() to have the same behaviour as
arch_get_unmapped_area(). Steve, any thoughts?
FWIW,
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
next prev parent reply other threads:[~2022-01-04 16:22 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-17 10:27 [PATCH v6 00/14] Convert powerpc to default topdown mmap layout Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 01/14] mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 02/14] mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 03/14] mm: Add len and flags parameters to arch_get_mmap_end() Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2022-01-04 16:09 ` Catalin Marinas
2022-01-04 16:09 ` Catalin Marinas
2022-01-04 16:09 ` Catalin Marinas
2021-12-17 10:27 ` [PATCH v6 04/14] mm, hugetlbfs: Allow for "high" userspace addresses Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2022-01-04 16:21 ` Catalin Marinas [this message]
2022-01-04 16:21 ` Catalin Marinas
2022-01-04 16:21 ` Catalin Marinas
2021-12-17 10:27 ` [PATCH v6 05/14] sizes.h: Add SZ_1T macro Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 06/14] powerpc/mm: Move vma_mmu_pagesize() Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 07/14] powerpc/mm: Make slice specific to book3s/64 Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 08/14] powerpc/mm: Remove CONFIG_PPC_MM_SLICES Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` [PATCH v6 09/14] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:27 ` Christophe Leroy
2021-12-17 10:28 ` [PATCH v6 10/14] powerpc/mm: Use generic_hugetlb_get_unmapped_area() Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` [PATCH v6 11/14] powerpc/mm: Move get_unmapped_area functions to slice.c Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` [PATCH v6 12/14] powerpc/mm: Enable full randomisation of memory mappings Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` [PATCH v6 13/14] powerpc/mm: Convert to default topdown mmap layout Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` [PATCH v6 14/14] powerpc: Simplify and move arch_randomize_brk() Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
2021-12-17 10:28 ` Christophe Leroy
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=YdR0EN2mdJuysugk@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=steve.capper@arm.com \
--cc=will.deacon@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.