linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Ghiti <alex@ghiti.fr>
To: Charlie Jenkins <charlie@rivosinc.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: conor@kernel.org, paul.walmsley@sifive.com, palmer@rivosinc.com,
	aou@eecs.berkeley.edu, anup@brainfault.org,
	konstantin@linuxfoundation.org, linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
	mick@ics.forth.gr, jrtc27@jrtc27.com
Subject: Re: [RESEND PATCH v3 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57
Date: Thu, 6 Jul 2023 11:11:37 +0200	[thread overview]
Message-ID: <2084462d-b11d-7a48-3049-6bafbe81e7b4@ghiti.fr> (raw)
In-Reply-To: <20230705190002.384799-2-charlie@rivosinc.com>

Hi Charlie,


On 05/07/2023 20:59, Charlie Jenkins wrote:
> Make sv48 the default address space for mmap as some applications
> currently depend on this assumption. The RISC-V specification enforces
> that bits outside of the virtual address range are not used, so
> restricting the size of the default address space as such should be
> temporary.


What do you mean in the last sentence above?


>   A hint address passed to mmap will cause the largest address
> space that fits entirely into the hint to be used. If the hint is less
> than or equal to 1<<38, an sv39 address will be used. An exception is
> that if the hint address is 0, then a sv48 address will be used.After
> an address space is completely full, the next smallest address space
> will be used.
>
> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> ---
>   arch/riscv/include/asm/elf.h       |  2 +-
>   arch/riscv/include/asm/pgtable.h   | 13 +++++++++++-
>   arch/riscv/include/asm/processor.h | 34 ++++++++++++++++++++++++------
>   3 files changed, 40 insertions(+), 9 deletions(-)
>
> diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h
> index 30e7d2455960..1b57f13a1afd 100644
> --- a/arch/riscv/include/asm/elf.h
> +++ b/arch/riscv/include/asm/elf.h
> @@ -49,7 +49,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
>    * the loader.  We need to make sure that it is out of the way of the program
>    * that it will "exec", and that there is sufficient room for the brk.
>    */
> -#define ELF_ET_DYN_BASE		((TASK_SIZE / 3) * 2)
> +#define ELF_ET_DYN_BASE		((DEFAULT_MAP_WINDOW / 3) * 2)
>   
>   #ifdef CONFIG_64BIT
>   #ifdef CONFIG_COMPAT
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index 75970ee2bda2..752e210c7547 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -57,18 +57,29 @@
>   #define MODULES_END		(PFN_ALIGN((unsigned long)&_start))
>   #endif
>   
> +
>   /*
>    * Roughly size the vmemmap space to be large enough to fit enough
>    * struct pages to map half the virtual address space. Then
>    * position vmemmap directly below the VMALLOC region.
>    */
>   #ifdef CONFIG_64BIT
> +#define VA_BITS_SV39 39
> +#define VA_BITS_SV48 48
> +#define VA_BITS_SV57 57
> +
> +#define VA_USER_SV39 (UL(1) << (VA_BITS_SV39 - 1))
> +#define VA_USER_SV48 (UL(1) << (VA_BITS_SV48 - 1))
> +#define VA_USER_SV57 (UL(1) << (VA_BITS_SV57 - 1))
> +
>   #define VA_BITS		(pgtable_l5_enabled ? \
> -				57 : (pgtable_l4_enabled ? 48 : 39))
> +				VA_BITS_SV57 : (pgtable_l4_enabled ? VA_BITS_SV48 : VA_BITS_SV39))
>   #else
>   #define VA_BITS		32
>   #endif
>   
> +#define DEFAULT_VA_BITS ((VA_BITS >= VA_BITS_SV48) ? VA_BITS_SV48 : VA_BITS)


Maybe rename DEFAULT_VA_BITS into MMAP_VA_BITS? Or something similar?


> +
>   #define VMEMMAP_SHIFT \
>   	(VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT)
>   #define VMEMMAP_SIZE	BIT(VMEMMAP_SHIFT)
> diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
> index 94a0590c6971..468a1f4b9da4 100644
> --- a/arch/riscv/include/asm/processor.h
> +++ b/arch/riscv/include/asm/processor.h
> @@ -12,20 +12,40 @@
>   
>   #include <asm/ptrace.h>
>   
> -/*
> - * This decides where the kernel will search for a free chunk of vm
> - * space during mmap's.
> - */
> -#define TASK_UNMAPPED_BASE	PAGE_ALIGN(TASK_SIZE / 3)
> -
> -#define STACK_TOP		TASK_SIZE
>   #ifdef CONFIG_64BIT
> +#define DEFAULT_MAP_WINDOW	(UL(1) << (DEFAULT_VA_BITS - 1))
>   #define STACK_TOP_MAX		TASK_SIZE_64
> +
> +#define arch_get_mmap_end(addr, len, flags) \
> +	((addr) >= VA_USER_SV57 ? STACK_TOP_MAX :   \
> +	 ((((addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) ? \
> +						 VA_USER_SV48 : \
> +						 VA_USER_SV39)
> +
> +#define arch_get_mmap_base(addr, base) \
> +	(((addr >= VA_USER_SV57) && (VA_BITS >= VA_BITS_SV57)) ?   \


So IIUC, a user must pass a hint larger than the max address of the mode 
the user wants right? Shouldn't the user rather pass an address that is 
larger than the previous mode? I mean if the user wants a 56-bit 
address, he should just pass an address above 1<<47 no?


> +		 VA_USER_SV57 - (DEFAULT_MAP_WINDOW - base) : \
> +	 ((((addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) ? \
> +		 VA_USER_SV48 - (DEFAULT_MAP_WINDOW - base) : \
> +	  (addr == 0) ? \
> +		 base : \
> +		 VA_USER_SV39 - (DEFAULT_MAP_WINDOW - base))
> +


Can you turn that into a function or use if/else statement? It's very 
hard to understand what happens there.

And riscv selects ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT which means the 
base is at the top of the address space (minus the stack IIRC). But if 
rlimit_stack is set to infinity (see mmap_base() 
https://elixir.bootlin.com/linux/latest/source/mm/util.c#L412), 
mmap_base is equal to TASK_UNMAPPED_BASE. Does that work in that case? 
It seems like this: VA_USER_SV39 - (DEFAULT_MAP_WINDOW - base)) would be 
negative right?

You should also add a rlimit test.


>   #else
> +#define DEFAULT_MAP_WINDOW	TASK_SIZE
>   #define STACK_TOP_MAX		TASK_SIZE
>   #endif
>   #define STACK_ALIGN		16
>   
> +
> +#define STACK_TOP		DEFAULT_MAP_WINDOW
> +
> +/*
> + * This decides where the kernel will search for a free chunk of vm
> + * space during mmap's.
> + */
> +#define TASK_UNMAPPED_BASE	PAGE_ALIGN(DEFAULT_MAP_WINDOW / 3)
> +
>   #ifndef __ASSEMBLY__
>   
>   struct task_struct;


  reply	other threads:[~2023-07-06  9:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 18:59 [RESEND PATCH v3 0/2] RISC-V: mm: Make SV48 the default address space Charlie Jenkins
2023-07-05 18:59 ` [RESEND PATCH v3 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57 Charlie Jenkins
2023-07-06  9:11   ` Alexandre Ghiti [this message]
2023-07-06 23:56     ` Charlie Jenkins
2023-07-07  0:52       ` Jessica Clarke
2023-07-05 18:59 ` [RESEND PATCH v3 2/2] RISC-V: mm: Update documentation and include test Charlie Jenkins
2023-07-06  5:30   ` Randy Dunlap
2023-07-06  9:17   ` Alexandre Ghiti
2023-07-05 20:00 ` [RESEND PATCH v3 0/2] RISC-V: mm: Make SV48 the default address space Conor Dooley
2023-07-05 20:50   ` Charlie Jenkins
2023-07-05 21:59     ` Conor Dooley

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=2084462d-b11d-7a48-3049-6bafbe81e7b4@ghiti.fr \
    --to=alex@ghiti.fr \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=charlie@rivosinc.com \
    --cc=conor@kernel.org \
    --cc=jrtc27@jrtc27.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mick@ics.forth.gr \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox