From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"alex@ghiti.fr" <alex@ghiti.fr>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 06/10] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area()
Date: Tue, 14 Dec 2021 00:02:32 +1100 [thread overview]
Message-ID: <87ee6gmzdj.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <8f54a8d097c402d808147b2044365ebfda2862dd.1638976229.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Use the generic version of arch_get_unmapped_area() which
> is now available at all time instead of its copy
> radix__arch_get_unmapped_area()
>
> Instead of setting mm->get_unmapped_area() to either
> arch_get_unmapped_area() or generic_get_unmapped_area(),
> always set it to arch_get_unmapped_area() and call
> generic_get_unmapped_area() from there when radix is enabled.
>
> Do the same with radix__arch_get_unmapped_area_topdown()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/mmap.c | 127 ++---------------------------------------
> 1 file changed, 6 insertions(+), 121 deletions(-)
>
> diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
> index 9b0d6e395bc0..46781d0103d1 100644
> --- a/arch/powerpc/mm/mmap.c
> +++ b/arch/powerpc/mm/mmap.c
> @@ -81,115 +81,15 @@ static inline unsigned long mmap_base(unsigned long rnd,
> }
>
> #ifdef HAVE_ARCH_UNMAPPED_AREA
> -#ifdef CONFIG_PPC_RADIX_MMU
> -/*
> - * Same function as generic code used only for radix, because we don't need to overload
> - * the generic one. But we will have to duplicate, because hash select
> - * HAVE_ARCH_UNMAPPED_AREA
> - */
> -static unsigned long
> -radix__arch_get_unmapped_area(struct file *filp, unsigned long addr,
> - unsigned long len, unsigned long pgoff,
> - unsigned long flags)
> -{
> - struct mm_struct *mm = current->mm;
> - struct vm_area_struct *vma;
> - int fixed = (flags & MAP_FIXED);
> - unsigned long high_limit;
> - struct vm_unmapped_area_info info;
> -
> - high_limit = DEFAULT_MAP_WINDOW;
> - if (addr >= high_limit || (fixed && (addr + len > high_limit)))
> - high_limit = TASK_SIZE;
> -
> - if (len > high_limit)
> - return -ENOMEM;
There are some differences in the above vs the generic code, the generic
arch_get_unmapped_area_topdown() in mm/mmap.c does:
const unsigned long mmap_end = arch_get_mmap_end(addr);
if (len > mmap_end - mmap_min_addr)
return -ENOMEM;
if (flags & MAP_FIXED)
return addr;
Our current code adjusts high_limit for fixed mappings that span above
the default map window. We added that logic in:
35602f82d0c7 ("powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary")
That means a fixed mapping that crosses the 128T boundary will be
allowed by our code.
On the other hand the generic code will allow a fixed mapping to cross
the 128T boundary, but only if the size of the mapping is < ~128T.
(The actual size limit is (128T - mmap_min_addr), which is usually 4K or
64K, but is adjustable.)
It's unlikely that any apps are doing fixed mappings larger than 128T
that cross the 128T boundary, but I think we need to allow it. 128T
seems like a lot, but is not compared to the entire 4PB address space.
So I think we need to fix that in the generic code.
The easiest option is probably to pass flags to arch_get_mmap_end(), and
then the arches can decide whether to adjust the return value based on
flags.
Then there's also the extra check we have here:
> - if (fixed) {
> - if (addr > high_limit - len)
> - return -ENOMEM;
> - return addr;
> - }
I think we can drop that when converting to the generic version, the
only case in which it matters is when high_limit == TASK_SIZE, and
get_unmapped_area() already does that check after calling us:
if (addr > TASK_SIZE - len)
return -ENOMEM;
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"alex@ghiti.fr" <alex@ghiti.fr>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
"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>
Subject: Re: [PATCH v4 06/10] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area()
Date: Tue, 14 Dec 2021 00:02:32 +1100 [thread overview]
Message-ID: <87ee6gmzdj.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <8f54a8d097c402d808147b2044365ebfda2862dd.1638976229.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Use the generic version of arch_get_unmapped_area() which
> is now available at all time instead of its copy
> radix__arch_get_unmapped_area()
>
> Instead of setting mm->get_unmapped_area() to either
> arch_get_unmapped_area() or generic_get_unmapped_area(),
> always set it to arch_get_unmapped_area() and call
> generic_get_unmapped_area() from there when radix is enabled.
>
> Do the same with radix__arch_get_unmapped_area_topdown()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/mmap.c | 127 ++---------------------------------------
> 1 file changed, 6 insertions(+), 121 deletions(-)
>
> diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
> index 9b0d6e395bc0..46781d0103d1 100644
> --- a/arch/powerpc/mm/mmap.c
> +++ b/arch/powerpc/mm/mmap.c
> @@ -81,115 +81,15 @@ static inline unsigned long mmap_base(unsigned long rnd,
> }
>
> #ifdef HAVE_ARCH_UNMAPPED_AREA
> -#ifdef CONFIG_PPC_RADIX_MMU
> -/*
> - * Same function as generic code used only for radix, because we don't need to overload
> - * the generic one. But we will have to duplicate, because hash select
> - * HAVE_ARCH_UNMAPPED_AREA
> - */
> -static unsigned long
> -radix__arch_get_unmapped_area(struct file *filp, unsigned long addr,
> - unsigned long len, unsigned long pgoff,
> - unsigned long flags)
> -{
> - struct mm_struct *mm = current->mm;
> - struct vm_area_struct *vma;
> - int fixed = (flags & MAP_FIXED);
> - unsigned long high_limit;
> - struct vm_unmapped_area_info info;
> -
> - high_limit = DEFAULT_MAP_WINDOW;
> - if (addr >= high_limit || (fixed && (addr + len > high_limit)))
> - high_limit = TASK_SIZE;
> -
> - if (len > high_limit)
> - return -ENOMEM;
There are some differences in the above vs the generic code, the generic
arch_get_unmapped_area_topdown() in mm/mmap.c does:
const unsigned long mmap_end = arch_get_mmap_end(addr);
if (len > mmap_end - mmap_min_addr)
return -ENOMEM;
if (flags & MAP_FIXED)
return addr;
Our current code adjusts high_limit for fixed mappings that span above
the default map window. We added that logic in:
35602f82d0c7 ("powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary")
That means a fixed mapping that crosses the 128T boundary will be
allowed by our code.
On the other hand the generic code will allow a fixed mapping to cross
the 128T boundary, but only if the size of the mapping is < ~128T.
(The actual size limit is (128T - mmap_min_addr), which is usually 4K or
64K, but is adjustable.)
It's unlikely that any apps are doing fixed mappings larger than 128T
that cross the 128T boundary, but I think we need to allow it. 128T
seems like a lot, but is not compared to the entire 4PB address space.
So I think we need to fix that in the generic code.
The easiest option is probably to pass flags to arch_get_mmap_end(), and
then the arches can decide whether to adjust the return value based on
flags.
Then there's also the extra check we have here:
> - if (fixed) {
> - if (addr > high_limit - len)
> - return -ENOMEM;
> - return addr;
> - }
I think we can drop that when converting to the generic version, the
only case in which it matters is when high_limit == TASK_SIZE, and
get_unmapped_area() already does that check after calling us:
if (addr > TASK_SIZE - len)
return -ENOMEM;
cheers
next prev parent reply other threads:[~2021-12-13 13:12 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-08 17:18 [PATCH v4 00/10] Convert powerpc to default topdown mmap layout Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 01/10] mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 02/10] mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-09 9:40 ` Nicholas Piggin
2021-12-09 9:40 ` Nicholas Piggin
2021-12-08 17:18 ` [PATCH v4 03/10] powerpc/mm: Move vma_mmu_pagesize() Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-09 9:36 ` Nicholas Piggin
2021-12-09 9:36 ` Nicholas Piggin
2021-12-08 17:18 ` [PATCH v4 04/10] powerpc/mm: Make slice specific to book3s/64 Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 05/10] powerpc/mm: Remove CONFIG_PPC_MM_SLICES Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 06/10] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-09 9:50 ` Nicholas Piggin
2021-12-09 9:50 ` Nicholas Piggin
2021-12-10 17:47 ` Christophe Leroy
2021-12-10 17:47 ` Christophe Leroy
2021-12-16 14:25 ` Christophe Leroy
2021-12-16 14:25 ` Christophe Leroy
2021-12-13 13:02 ` Michael Ellerman [this message]
2021-12-13 13:02 ` Michael Ellerman
2021-12-08 17:18 ` [PATCH v4 08/10] powerpc/mm: Move get_unmapped_area functions to slice.c Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 07/10] powerpc/mm: Use generic_hugetlb_get_unmapped_area() Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-09 10:02 ` Nicholas Piggin
2021-12-09 10:02 ` Nicholas Piggin
2021-12-16 17:13 ` Christophe Leroy
2021-12-16 17:13 ` Christophe Leroy
2021-12-16 17:13 ` Christophe Leroy
2021-12-16 18:55 ` Catalin Marinas
2021-12-16 18:55 ` Catalin Marinas
2021-12-16 18:55 ` Catalin Marinas
2021-12-08 17:18 ` [PATCH v4 09/10] powerpc/mm: Convert to default topdown mmap layout Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-09 10:15 ` Nicholas Piggin
2021-12-09 10:15 ` Nicholas Piggin
2021-12-09 10:22 ` Christophe Leroy
2021-12-09 10:22 ` Christophe Leroy
2021-12-09 10:43 ` Nicholas Piggin
2021-12-09 10:43 ` Nicholas Piggin
2021-12-09 11:22 ` Michael Ellerman
2021-12-09 11:22 ` Michael Ellerman
2021-12-09 11:32 ` Christophe Leroy
2021-12-09 11:32 ` Christophe Leroy
2021-12-09 23:56 ` Michael Ellerman
2021-12-09 23:56 ` Michael Ellerman
2021-12-16 14:27 ` Christophe Leroy
2021-12-16 14:27 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 10/10] powerpc/mm: Properly randomise mmap with slices Christophe Leroy
2021-12-08 17:18 ` 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=87ee6gmzdj.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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.