riscv: mm: Fixup & Optimize COMPAT code
Subsystems (2)
v2 cover riscv: mm: Fixup & Optimize COMPAT code
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the TASK_SIZE should be 2GB, so STACK_TOP_MAX and arch_get_mmap_end must be limited to 2 GB. This series fixes the problem made by commit: add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") and optimizes the related coding convention of TASK_SIZE.
Changelog:
v2:
- Separate rename from fixup
- Add STACK_TOP_MAX fixup for compat
- Add Cleanup & rename patches
v1:
https://lore.kernel.org/linux-riscv/[email protected]/
Guo Ren (4):
riscv: mm: Fixup compat mode boot failure
riscv: mm: Fixup compat arch_get_mmap_end
riscv: mm: Remove unused TASK_SIZE_MIN
riscv: mm: Optimize TASK_SIZE definition
arch/riscv/include/asm/pgtable.h | 9 ++++----- arch/riscv/include/asm/processor.h | 6 ++---- 2 files changed, 6 insertions(+), 9 deletions(-)
Signature · 1 line
2.40.1
PATCH v2 1/4 riscv: mm: Fixup compat mode boot failure
From: Guo Ren <[email protected]>
In COMPAT mode, the STACK_TOP is 0x80000000, but the TASK_SIZE is 0x7fff000. When the user stack is upon 0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.
Freeing unused kernel image (initmem) memory: 2236K
Run /sbin/init as init process
Starting init: /sbin/init exists but couldn't execute it (error -14) Run /etc/init as init process
...
--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/pgtable.h +1 -1
@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
Signature · 1 line
2.40.1
Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Hello Guo Ren,
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:58AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
In COMPAT mode, the
STACK_TOPis0x80000000, but theTASK_SIZEis0x7fff000. When the user stack is upon0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.
Checking if I get the scenario:
In pgtable.h:
#ifdef CONFIG_64BIT
#define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2)
#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)
#ifdef CONFIG_COMPAT
#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE)
#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)#else
[...]
Meaning CONFIG_COMPAT is only available in CONFIG_64BIT, and TASK_SIZE in compat mode is either TASK_SIZE_32 or TASK_SIZE_64 depending on the thread_flag.
from processor.h:
#ifdef CONFIG_64BIT
#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1))
#define STACK_TOP_MAX TASK_SIZE_64
[...]
#define STACK_TOP DEFAULT_MAP_WINDOW
where:
#define MMAP_VA_BITS (is_compat_task() ? VA_BITS_SV32 : MMAP_VA_BITS_64) with MMAP_VA_BITS_64 being either 48 or 37.
In compat mode,STACK_TOP = 1 << (32 - 1) -> 0x80000000TASK_SIZE = 0x8000000 - 4k -> 0x7ffff000
IIUC, your suggestion is to make TASK_SIZE = STACK_TOP in compat mode only.
Then why not:
#ifdef CONFIG_COMPAT
#define TASK_SIZE_32 STACK_TOP
With some comments explaining why there is no need to reserve a PAGE_SIZE in the TASK_SIZE_32.
Does that make sense?
Thanks!
Leo
Quoted 35 lines
Freeing unused kernel image (initmem) memory: 2236K
Run/sbin/initas init process
Starting init:/sbin/initexists but couldn't execute it (error -14) Run/etc/initas init process
...Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/riscv/include/asm/pgtable.h +1
-1@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define
TASK_SIZE(test_thread_flag(TIF_32BIT)? \
TASK_SIZE_32:TASK_SIZE_64)
#elseSignature · 1 line
2.40.1
Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Quoted 40 lines · Leonardo Bras
Hello Guo Ren,
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:58AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
In COMPAT mode, the
STACK_TOPis0x80000000, but theTASK_SIZEis0x7fff000. When the user stack is upon0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.Checking if I get the scenario:
In
pgtable.h:
#ifdefCONFIG_64BIT
#defineTASK_SIZE_64(PGDIR_SIZE*PTRS_PER_PGD/ 2)
#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)#ifdef
CONFIG_COMPAT
#defineTASK_SIZE_32(_AC(0x80000000, UL)-PAGE_SIZE)#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
[...]Meaning
CONFIG_COMPATis only available inCONFIG_64BIT, andTASK_SIZEin compat mode is eitherTASK_SIZE_32orTASK_SIZE_64depending on thethread_flag.from
processor.h:
#ifdefCONFIG_64BIT
#defineDEFAULT_MAP_WINDOW(UL(1) << (MMAP_VA_BITS- 1))
#defineSTACK_TOP_MAXTASK_SIZE_64
[...]
#defineSTACK_TOPDEFAULT_MAP_WINDOWwhere:
#defineMMAP_VA_BITS(is_compat_task()?VA_BITS_SV32:MMAP_VA_BITS_64) withMMAP_VA_BITS_64being either 48 or 37.
Quoted 5 lines
In compat mode,
STACK_TOP= 1 << (32 - 1) ->0x80000000TASK_SIZE=0x8000000- 4k ->0x7ffff000IIUC, your suggestion is to make
TASK_SIZE=STACK_TOPin compat mode only.
Yes, it causes the problem, which causes the boot to fail.
Quoted 4 lines
Then why not:
#ifdefCONFIG_COMPAT
#defineTASK_SIZE_32STACK_TOP
Yes, it's the solution that I think at first. But I didn't find any problem with 0x7ffff000 ~ 0x80000000, and then I removed this gap to unify it with Sv39 and Sv48.
Quoted 3 lines
With some comments explaining why there is no need to reserve a
PAGE_SIZEin theTASK_SIZE_32.
At first, I wanted to put a invalid page between the user & kernel space, but it seems useless.
Quoted 42 lines
Does that make sense?
Thanks!
LeoQuoted 35 lines
Freeing unused kernel image (initmem) memory: 2236K
Run/sbin/initas init process
Starting init:/sbin/initexists but couldn't execute it (error -14) Run/etc/initas init process
...Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/riscv/include/asm/pgtable.h +1
-1@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
--
2.40.1
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Quoted 41 lines · Guo Ren
Quoted 40 lines · Leonardo Bras
Hello Guo Ren,
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:58AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
In COMPAT mode, the
STACK_TOPis0x80000000, but theTASK_SIZEis0x7fff000. When the user stack is upon0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.Checking if I get the scenario:
In
pgtable.h:
#ifdefCONFIG_64BIT
#defineTASK_SIZE_64(PGDIR_SIZE*PTRS_PER_PGD/ 2)
#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)#ifdef
CONFIG_COMPAT
#defineTASK_SIZE_32(_AC(0x80000000, UL)-PAGE_SIZE)#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
[...]Meaning
CONFIG_COMPATis only available inCONFIG_64BIT, andTASK_SIZEin compat mode is eitherTASK_SIZE_32orTASK_SIZE_64depending on thethread_flag.from
processor.h:
#ifdefCONFIG_64BIT
#defineDEFAULT_MAP_WINDOW(UL(1) << (MMAP_VA_BITS- 1))
#defineSTACK_TOP_MAXTASK_SIZE_64
[...]
#defineSTACK_TOPDEFAULT_MAP_WINDOWwhere:
#defineMMAP_VA_BITS(is_compat_task()?VA_BITS_SV32:MMAP_VA_BITS_64) withMMAP_VA_BITS_64being either 48 or 37.
Quoted 6 lines
Quoted 5 lines
In compat mode,
STACK_TOP= 1 << (32 - 1) ->0x80000000TASK_SIZE=0x8000000- 4k ->0x7ffff000IIUC, your suggestion is to make
TASK_SIZE=STACK_TOPin compat mode only.Yes, it causes the problem, which causes the boot to fail.
I think what Leonardo is getting at is that it is odd that it would cause boot issues if TASK_SIZE is not equal STACK_TOP. This seems indicative of a different problem. While this may fix the issue, it should be valid for TASK_SIZE to be less than STACK_TOP.
- Charlie
Quoted 62 lines
Quoted 5 lines
Then why not:
#ifdefCONFIG_COMPAT
#defineTASK_SIZE_32STACK_TOPYes, it's the solution that I think at first. But I didn't find any problem with
0x7ffff000~0x80000000, and then I removed this gap to unify it with Sv39 and Sv48.Quoted 3 lines
With some comments explaining why there is no need to reserve a
PAGE_SIZEin theTASK_SIZE_32.At first, I wanted to put a invalid page between the user & kernel space, but it seems useless.
Quoted 42 lines
Does that make sense?
Thanks!
LeoQuoted 35 lines
Freeing unused kernel image (initmem) memory: 2236K
Run/sbin/initas init process
Starting init:/sbin/initexists but couldn't execute it (error -14) Run/etc/initas init process
...Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/riscv/include/asm/pgtable.h +1
-1@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
--
2.40.1Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Quoted 47 lines · Charlie Jenkins
Quoted 46 lines · Guo Ren
Quoted 45 lines · Leonardo Bras
Hello Guo Ren,
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:58AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
In COMPAT mode, the
STACK_TOPis0x80000000, but theTASK_SIZEis0x7fff000. When the user stack is upon0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.Checking if I get the scenario:
In
pgtable.h:
#ifdefCONFIG_64BIT
#defineTASK_SIZE_64(PGDIR_SIZE*PTRS_PER_PGD/ 2)
#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)#ifdef
CONFIG_COMPAT
#defineTASK_SIZE_32(_AC(0x80000000, UL)-PAGE_SIZE)#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
[...]Meaning
CONFIG_COMPATis only available inCONFIG_64BIT, andTASK_SIZEin compat mode is eitherTASK_SIZE_32orTASK_SIZE_64depending on thethread_flag.from
processor.h:
#ifdefCONFIG_64BIT
#defineDEFAULT_MAP_WINDOW(UL(1) << (MMAP_VA_BITS- 1))
#defineSTACK_TOP_MAXTASK_SIZE_64
[...]
#defineSTACK_TOPDEFAULT_MAP_WINDOWwhere:
#defineMMAP_VA_BITS(is_compat_task()?VA_BITS_SV32:MMAP_VA_BITS_64) withMMAP_VA_BITS_64being either 48 or 37.In compat mode,
STACK_TOP= 1 << (32 - 1) ->0x80000000TASK_SIZE=0x8000000- 4k ->0x7ffff000IIUC, your suggestion is to make
TASK_SIZE=STACK_TOPin compat mode only.
Quoted 9 lines
Quoted 1 line
Yes, it causes the problem, which causes the boot to fail.
I think what Leonardo is getting at is that it is odd that it would cause boot issues if
TASK_SIZEis not equalSTACK_TOP. This seems indicative of a different problem. While this may fix the issue, it should be valid forTASK_SIZEto be less thanSTACK_TOP.- Charlie
That is also a good point, but I am not that acquainted to this to actually propose this.
I was thinking more on these questions:
Is TASK_SIZE and STACK_TOP related somehow?
If so, would not be better to describe one in terms of the other, like #define TASK_SIZE (STACK_TOP - PAGE_SIZE)
Or the other way around.
I mean, if they have any relation it would be much easier to represent them that way, and it would avoid having two magical numbers.
Thanks!
Leo
Quoted 63 lines
Quoted 62 lines
Quoted 5 lines
Then why not:
#ifdefCONFIG_COMPAT
#defineTASK_SIZE_32STACK_TOPYes, it's the solution that I think at first. But I didn't find any problem with
0x7ffff000~0x80000000, and then I removed this gap to unify it with Sv39 and Sv48.Quoted 3 lines
With some comments explaining why there is no need to reserve a
PAGE_SIZEin theTASK_SIZE_32.At first, I wanted to put a invalid page between the user & kernel space, but it seems useless.
Quoted 42 lines
Does that make sense?
Thanks!
LeoQuoted 35 lines
Freeing unused kernel image (initmem) memory: 2236K
Run/sbin/initas init process
Starting init:/sbin/initexists but couldn't execute it (error -14) Run/etc/initas init process
...Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/riscv/include/asm/pgtable.h +1
-1@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
--
2.40.1Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Quoted 59 lines · Leonardo Bras
Quoted 47 lines · Charlie Jenkins
Quoted 46 lines · Guo Ren
Quoted 45 lines · Leonardo Bras
Hello Guo Ren,
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:58AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
In COMPAT mode, the
STACK_TOPis0x80000000, but theTASK_SIZEis0x7fff000. When the user stack is upon0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.Checking if I get the scenario:
In
pgtable.h:
#ifdefCONFIG_64BIT
#defineTASK_SIZE_64(PGDIR_SIZE*PTRS_PER_PGD/ 2)
#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)#ifdef
CONFIG_COMPAT
#defineTASK_SIZE_32(_AC(0x80000000, UL)-PAGE_SIZE)#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
[...]Meaning
CONFIG_COMPATis only available inCONFIG_64BIT, andTASK_SIZEin compat mode is eitherTASK_SIZE_32orTASK_SIZE_64depending on thethread_flag.from
processor.h:
#ifdefCONFIG_64BIT
#defineDEFAULT_MAP_WINDOW(UL(1) << (MMAP_VA_BITS- 1))
#defineSTACK_TOP_MAXTASK_SIZE_64
[...]
#defineSTACK_TOPDEFAULT_MAP_WINDOWwhere:
#defineMMAP_VA_BITS(is_compat_task()?VA_BITS_SV32:MMAP_VA_BITS_64) withMMAP_VA_BITS_64being either 48 or 37.In compat mode,
STACK_TOP= 1 << (32 - 1) ->0x80000000TASK_SIZE=0x8000000- 4k ->0x7ffff000IIUC, your suggestion is to make
TASK_SIZE=STACK_TOPin compat mode only.Quoted 9 lines
Quoted 1 line
Yes, it causes the problem, which causes the boot to fail.
I think what Leonardo is getting at is that it is odd that it would cause boot issues if
TASK_SIZEis not equalSTACK_TOP. This seems indicative of a different problem. While this may fix the issue, it should be valid forTASK_SIZEto be less thanSTACK_TOP.- Charlie
Quoted 7 lines
That is also a good point, but I am not that acquainted to this to actually propose this.
I was thinking more on these questions:
IsTASK_SIZEandSTACK_TOPrelated somehow?
If so, would not be better to describe one in terms of the other, like #defineTASK_SIZE(STACK_TOP-PAGE_SIZE)
TASK_SIZE means the maximum user address space, so it's the limitation to any kind of mmap or stack ...
So STACK_TOP <= TASK_SIZE
Follow your idea. The question is:
#define TASK_SIZE ((UL(1) << (VA_BITS - 1)) - PAGE_SIZE)
Do we need to reserve one page between userspace & kernel?
Quoted 73 lines
Or the other way around.
I mean, if they have any relation it would be much easier to represent them that way, and it would avoid having two magical numbers.
Thanks!
LeoQuoted 63 lines
Quoted 62 lines
Quoted 5 lines
Then why not:
#ifdefCONFIG_COMPAT
#defineTASK_SIZE_32STACK_TOPYes, it's the solution that I think at first. But I didn't find any problem with
0x7ffff000~0x80000000, and then I removed this gap to unify it with Sv39 and Sv48.Quoted 3 lines
With some comments explaining why there is no need to reserve a
PAGE_SIZEin theTASK_SIZE_32.At first, I wanted to put a invalid page between the user & kernel space, but it seems useless.
Quoted 42 lines
Does that make sense?
Thanks!
LeoQuoted 35 lines
Freeing unused kernel image (initmem) memory: 2236K
Run/sbin/initas init process
Starting init:/sbin/initexists but couldn't execute it (error -14) Run/etc/initas init process
...Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/riscv/include/asm/pgtable.h +1
-1@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
--
2.40.1--
Best Regards
Guo Ren
--
Best Regards
Guo Ren
Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
In reply to Charlie JenkinsHello Charlie,
Quoted 47 lines · Charlie Jenkins
Quoted 45 lines · Guo Ren
Quoted 44 lines · Leonardo Bras
Hello Guo Ren,
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:58AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
In COMPAT mode, the
STACK_TOPis0x80000000, but theTASK_SIZEis0x7fff000. When the user stack is upon0x7fff000, it will cause a user segment fault. Sometimes, it would cause boot failure when the whole rootfs is rv32.Checking if I get the scenario:
In
pgtable.h:
#ifdefCONFIG_64BIT
#defineTASK_SIZE_64(PGDIR_SIZE*PTRS_PER_PGD/ 2)
#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)#ifdef
CONFIG_COMPAT
#defineTASK_SIZE_32(_AC(0x80000000, UL)-PAGE_SIZE)#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
[...]Meaning
CONFIG_COMPATis only available inCONFIG_64BIT, andTASK_SIZEin compat mode is eitherTASK_SIZE_32orTASK_SIZE_64depending on thethread_flag.from
processor.h:
#ifdefCONFIG_64BIT
#defineDEFAULT_MAP_WINDOW(UL(1) << (MMAP_VA_BITS- 1))
#defineSTACK_TOP_MAXTASK_SIZE_64
[...]
#defineSTACK_TOPDEFAULT_MAP_WINDOWwhere:
#defineMMAP_VA_BITS(is_compat_task()?VA_BITS_SV32:MMAP_VA_BITS_64) withMMAP_VA_BITS_64being either 48 or 37.In compat mode,
STACK_TOP= 1 << (32 - 1) ->0x80000000TASK_SIZE=0x8000000- 4k ->0x7ffff000
Quoted 7 lines
Quoted 2 lines
Quoted 1 line
IIUC, your suggestion is to make
TASK_SIZE=STACK_TOPin compat mode only.Yes, it causes the problem, which causes the boot to fail.
I think what Leonardo is getting at is that it is odd that it would cause boot issues if
TASK_SIZEis not equalSTACK_TOP. This seems indicative of a different problem. While this may fix the issue, it should be valid forTASK_SIZEto be less thanSTACK_TOP.
Sorry, I don't make sense here. Why do you think STACK_TOP could > TASK_SIZE? TASK_SIZE is the highest priority of the address limitation for user-space address, right?
Do you mean:STACK_TOP could > MMAP_END?
Quoted 65 lines
- Charlie
Quoted 62 lines
Quoted 5 lines
Then why not:
#ifdefCONFIG_COMPAT
#defineTASK_SIZE_32STACK_TOPYes, it's the solution that I think at first. But I didn't find any problem with
0x7ffff000~0x80000000, and then I removed this gap to unify it with Sv39 and Sv48.Quoted 3 lines
With some comments explaining why there is no need to reserve a
PAGE_SIZEin theTASK_SIZE_32.At first, I wanted to put a invalid page between the user & kernel space, but it seems useless.
Quoted 42 lines
Does that make sense?
Thanks!
LeoQuoted 35 lines
Freeing unused kernel image (initmem) memory: 2236K
Run/sbin/initas init process
Starting init:/sbin/initexists but couldn't execute it (error -14) Run/etc/initas init process
...Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/riscv/include/asm/pgtable.h +1
-1@@ -881,7 +881,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL) - PAGE_SIZE) +#define TASK_SIZE_32 (_AC(0x80000000, UL))#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64)#else
--
2.40.1--
Best Regards
Guo Ren
Signature · 2 lines
Best Regards Guo Ren
PATCH v2 2/4 riscv: mm: Fixup compat arch_get_mmap_end
In reply to [email protected]From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the arch_get_mmap_end should be 2GB, not TASK_SIZE_64. The TASK_SIZE has contained is_compat_mode() detection, so change the definition of STACK_TOP_MAX to TASK_SIZE directly.
--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
arch/riscv/include/asm/processor.h +2 -4
@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZE#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \
Signature · 1 line
2.40.1
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.
ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0
arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZE
It means STACK_TOP_MAX will be in 64BIT:
- TASK_SIZE_32 if compat_mode=y
- TASK_SIZE_64 if compat_mode=n
Makes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \
I don't think I got this change, or how it's connected to the commit msg.
Before:
- addr == 0, or addr > 2^57, or compat: mmap_end = STACK_TOP_MAX
- 2^48 < addr < 2^57: mmap_end = 2^48
- 0 < addr < 2^48 : mmap_end = 2^39
Now:
- addr == 0, or addr > 2^57: mmap_end = STACK_TOP_MAX
- 2^48 < addr < 2^57: mmap_end = 2^48
- 0 < addr < 2^48 : mmap_end = 2^39
IIUC compat mode addr will be < 2^32, so will always have mmap_end = 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)
Also, unrelated to the change:
- 2^48 < addr < 2^57: mmap_end = 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should have mmap_end = 2^48.
Do I get it wrong?
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
Leo
Quoted 3 lines
Signature · 1 line
2.40.1
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 57 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \I don't think I got this change, or how it's connected to the commit msg.
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39
Quoted 8 lines
Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)
I agree, this change does not make sense for compat mode. Compat mode should never return an address that is greater than 2^32, but this change allows that.
Quoted 6 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.
That is not the case. I documented this behavior and reasoning in Documentation/arch/riscv/vm-layout.rst in the "Userspace VAs" section.
I can reiterate here though. The hint address to mmap (defined here as "addr") is the maximum userspace address that mmap should provide. What you are describing is a minimum. The purpose of this change was to allow applications that are not compatible with a larger virtual address (such as applications like Java that use the upper bits of the VA to store data) to have a consistent way of specifying how many bits they would like to be left free in the VA. This requires to take the next lowest address space to guaruntee that all of the most-significant bits left clear in hint address do not end up populated in the virtual address returned by mmap.
- Charlie
Quoted 17 lines
Do I get it wrong?
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
Signature · 1 line
2.40.1
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 92 lines · Charlie Jenkins
Quoted 57 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \I don't think I got this change, or how it's connected to the commit msg.
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Quoted 8 lines
Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)I agree, this change does not make sense for compat mode. Compat mode should never return an address that is greater than 2^32, but this change allows that.
Quoted 6 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.That is not the case. I documented this behavior and reasoning in
Documentation/arch/riscv/vm-layout.rstin the "Userspace VAs" section.I can reiterate here though. The hint address to mmap (defined here as "addr") is the maximum userspace address that mmap should provide. What you are describing is a minimum. The purpose of this change was to allow applications that are not compatible with a larger virtual address (such as applications like Java that use the upper bits of the VA to store data) to have a consistent way of specifying how many bits they would like to be left free in the VA. This requires to take the next lowest address space to guaruntee that all of the most-significant bits left clear in hint address do not end up populated in the virtual address returned by mmap.
Quoted 1 line
- Charlie
Hello Charlie, thank you for helping me understand!
Ok, that does make sense now! The addr value hints "don't allocate > addr" and thus:
- 0 < addr < 2^48 : mmap_end = 2^39
- 2^48 < addr < 2^57: mmap_end = 2^48
Ok, but then
- addr > 2^57: mmap_end = 2^57
right?
I mean, probably STACK_TOP_MAX in non-compat mode means 2^57 already, but having it explicitly like:
else if ((_addr) >= VA_USER_SV57) \
mmap_end = VA_USER_SV57; \would not be better for a future full 64-bit addressing? (since it's already on a different if clause)
I could add comment on top of the macro with a short version on your addr hint description above. Would that be ok?
Thanks!
Leo
Quoted 19 lines
Quoted 18 lines
Do I get it wrong?
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
Signature · 1 line
2.40.1
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 107 lines · Leonardo Bras
Quoted 92 lines · Charlie Jenkins
Quoted 57 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \I don't think I got this change, or how it's connected to the commit msg.
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Quoted 8 lines
Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)I agree, this change does not make sense for compat mode. Compat mode should never return an address that is greater than 2^32, but this change allows that.
Quoted 6 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.That is not the case. I documented this behavior and reasoning in
Documentation/arch/riscv/vm-layout.rstin the "Userspace VAs" section.I can reiterate here though. The hint address to mmap (defined here as "addr") is the maximum userspace address that mmap should provide. What you are describing is a minimum. The purpose of this change was to allow applications that are not compatible with a larger virtual address (such as applications like Java that use the upper bits of the VA to store data) to have a consistent way of specifying how many bits they would like to be left free in the VA. This requires to take the next lowest address space to guaruntee that all of the most-significant bits left clear in hint address do not end up populated in the virtual address returned by mmap.
Quoted 1 line
- Charlie
Hello Charlie, thank you for helping me understand!
Ok, that does make sense now! The addr value hints "don't allocate > addr" and thus:
- 0 < addr < 2^48 :
mmap_end= 2^39
- 2^48 < addr < 2^57:mmap_end= 2^48Ok, but then
- addr > 2^57:mmap_end= 2^57
right?
Quoted 8 lines
I mean, probably
STACK_TOP_MAXin non-compat mode means 2^57 already, but having it explicitly like:else if ((_addr) >= VA_USER_SV57) \ mmap_end = VA_USER_SV57; \would not be better for a future full 64-bit addressing? (since it's already on a different if clause)
I agree, that does make more sense.
Quoted 3 lines
I could add comment on top of the macro with a short version on your addr hint description above. Would that be ok?
Sure :)
- Charlie
Quoted 28 lines
Thanks!
LeoQuoted 19 lines
Quoted 18 lines
Do I get it wrong?
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
Signature · 1 line
2.40.1
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 117 lines · Charlie Jenkins
Quoted 107 lines · Leonardo Bras
Quoted 92 lines · Charlie Jenkins
Quoted 57 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \I don't think I got this change, or how it's connected to the commit msg.
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Quoted 8 lines
Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)I agree, this change does not make sense for compat mode. Compat mode should never return an address that is greater than 2^32, but this change allows that.
Quoted 6 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.That is not the case. I documented this behavior and reasoning in
Documentation/arch/riscv/vm-layout.rstin the "Userspace VAs" section.I can reiterate here though. The hint address to mmap (defined here as "addr") is the maximum userspace address that mmap should provide. What you are describing is a minimum. The purpose of this change was to allow applications that are not compatible with a larger virtual address (such as applications like Java that use the upper bits of the VA to store data) to have a consistent way of specifying how many bits they would like to be left free in the VA. This requires to take the next lowest address space to guaruntee that all of the most-significant bits left clear in hint address do not end up populated in the virtual address returned by mmap.
Quoted 1 line
- Charlie
Hello Charlie, thank you for helping me understand!
Ok, that does make sense now! The addr value hints "don't allocate > addr" and thus:
- 0 < addr < 2^48 :
mmap_end= 2^39
- 2^48 < addr < 2^57:mmap_end= 2^48Ok, but then
- addr > 2^57:mmap_end= 2^57
right?Quoted 8 lines
I mean, probably
STACK_TOP_MAXin non-compat mode means 2^57 already, but having it explicitly like:else if ((_addr) >= VA_USER_SV57) \ mmap_end = VA_USER_SV57; \would not be better for a future full 64-bit addressing? (since it's already on a different if clause)
Quoted 7 lines
I agree, that does make more sense.
Quoted 3 lines
I could add comment on top of the macro with a short version on your addr hint description above. Would that be ok?
Sure :)
Sent, thanks!
Leo
Quoted 32 lines
- Charlie
Quoted 28 lines
Thanks!
LeoQuoted 19 lines
Quoted 18 lines
Do I get it wrong?
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
Signature · 1 line
2.40.1
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
In reply to Charlie JenkinsQuoted 64 lines · Charlie Jenkins
Quoted 62 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \I don't think I got this change, or how it's connected to the commit msg.
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39
Quoted 7 lines
Quoted 3 lines
IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)I agree, this change does not make sense for compat mode. Compat mode should never return an address that is greater than 2^32, but this change allows that.
#define STACK_TOP_MAX TASK_SIZE
#define TASK_SIZE (is_compat_task() ? TASK_SIZE_32 : TASK_SIZE_64)
So, this change limits an address in 2^32 for compat mode, and your patch broke the rule. So that is why we need this patch to fix up.
Quoted 11 lines
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.That is not the case. I documented this behavior and reasoning in
Documentation/arch/riscv/vm-layout.rstin the "Userspace VAs" section.
Quoted 6 lines
I can reiterate here though. The hint address to mmap (defined here as "addr") is the maximum userspace address that mmap should provide. What you are describing is a minimum. The purpose of this change was to allow applications that are not compatible with a larger virtual address (such as applications like Java that use the upper bits of the VA to store data) to have a consistent way of specifying how many bits they would
Yes, I agree with this change and use Zjpm with PLEN=48 to optimize them in the future.
Quoted 24 lines
like to be left free in the VA. This requires to take the next lowest address space to guaruntee that all of the most-significant bits left clear in hint address do not end up populated in the virtual address returned by mmap.
- Charlie
Quoted 17 lines
Do I get it wrong?
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
In reply to Leonardo BrasQuoted 51 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \
Quoted 1 line
I don't think I got this change, or how it's connected to the commit msg.
The above is just code simplification; if STACK_TOP_MAX is TASK_SIZE, then
if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \
mmap_end = STACK_TOP_MAX; \
else if ((_addr) >= VA_USER_SV57) \is equal to:
if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \
Quoted 15 lines
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.Do I get it wrong?
Maybe I should move this into the optimization part.
Quoted 15 lines
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 55 lines · Guo Ren
Quoted 51 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \Quoted 1 line
I don't think I got this change, or how it's connected to the commit msg.
The above is just code simplification; if
STACK_TOP_MAXisTASK_SIZE, then
Quoted 7 lines
if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ mmap_end = STACK_TOP_MAX; \ else if ((_addr) >= VA_USER_SV57) \is equal to:
if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \
I am failing to understand exactly how are they equal. I mean, what in your STACK_TOP_MAX change made them equal?
See below, the behavior changed:
Quoted 12 lines
Quoted 12 lines
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39
Quoted 4 lines
Quoted 4 lines
IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)
^
With your change on STACK_TOP_MAX only (not changing arch_get_mmap_end), you would have:
- compat_mode & (0 < addr < 2^32) -> mmap_end = 2^32
- non-compat, addr == 0, or addr > 2^57 -> mmap_end = TASK_SIZE_64
- non-compat, (2^48 < addr < 2^57) -> mmap_end = 2^48
- non-compat, (0 < addr < 2^48) -> mmap_end = 2^39
Which seems more likely, based on Charlie comments.
Thanks,
Leo
Quoted 30 lines
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.Do I get it wrong?
Maybe I should move this into the optimization part.
Quoted 15 lines
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 61 lines · Leonardo Bras
Quoted 59 lines · Guo Ren
Quoted 51 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \Quoted 1 line
I don't think I got this change, or how it's connected to the commit msg.
The above is just code simplification; if
STACK_TOP_MAXisTASK_SIZE, thenif ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ mmap_end = STACK_TOP_MAX; \ else if ((_addr) >= VA_USER_SV57) \
Quoted 6 lines
Quoted 3 lines
is equal to:
if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \I am failing to understand exactly how are they equal. I mean, what in your
STACK_TOP_MAXchange made them equal?
#define STACK_TOP_MAX TASK_SIZE
#define TASK_SIZE (is_compat_task() ? TASK_SIZE_32 : TASK_SIZE_64)
Quoted 19 lines
See below, the behavior changed:
Quoted 12 lines
Quoted 12 lines
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Quoted 4 lines
Quoted 4 lines
IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)
Quoted 6 lines
^
With your change on
STACK_TOP_MAXonly (not changingarch_get_mmap_end), you would have:-
compat_mode& (0 < addr < 2^32) ->mmap_end= 2^32
compat_mode -> mmap_end = 2^32
Quoted 40 lines
- non-compat, addr == 0, or addr > 2^57 ->
mmap_end=TASK_SIZE_64
- non-compat, (2^48 < addr < 2^57) ->mmap_end= 2^48
- non-compat, (0 < addr < 2^48) ->mmap_end= 2^39Which seems more likely, based on Charlie comments.
Thanks,
LeoQuoted 30 lines
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.Do I get it wrong?
Maybe I should move this into the optimization part.
Quoted 15 lines
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
--
Best Regards
Guo Ren
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 62 lines · Guo Ren
Quoted 61 lines · Leonardo Bras
Quoted 59 lines · Guo Ren
Quoted 51 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \Quoted 1 line
I don't think I got this change, or how it's connected to the commit msg.
The above is just code simplification; if
STACK_TOP_MAXisTASK_SIZE, thenif ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ mmap_end = STACK_TOP_MAX; \ else if ((_addr) >= VA_USER_SV57) \
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
is equal to:
if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \I am failing to understand exactly how are they equal. I mean, what in your
STACK_TOP_MAXchange made them equal?#define
STACK_TOP_MAXTASK_SIZE
#defineTASK_SIZE(is_compat_task()?TASK_SIZE_32:TASK_SIZE_64)
yes, I am aware. Let's do a simple test with the new code and addr = 2^27 (random 32-bit addr) and compat mode.
if ((_addr) == 0 || (_addr) >= VA_USER_SV57)
// Evaluates to false: 2^27 != 0, and is < 2^57 else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) // Evaluates to false: 2^27 < 2^48 else mmap_end = VA_USER_SV39;
mmap_end = VA_USER_SV39, even in compat_mode.
We need the extra is_compat_task() if we want to return 2^32.
Thanks!
Leo
Quoted 19 lines
Quoted 19 lines
See below, the behavior changed:
Quoted 16 lines
Quoted 16 lines
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)
Quoted 8 lines
Quoted 6 lines
^
With your change on
STACK_TOP_MAXonly (not changingarch_get_mmap_end), you would have:-
compat_mode& (0 < addr < 2^32) ->mmap_end= 2^32
compat_mode->mmap_end= 2^32
This is correct!
Yeah, since you changed STACK_TOP_MAX to be 2^32 in compat mode, any addr value < 2^32 with compat value will return 2^32. (without the change in arch_get_mmap_end(), that is.)
Quoted 46 lines
Quoted 40 lines
- non-compat, addr == 0, or addr > 2^57 ->
mmap_end=TASK_SIZE_64
- non-compat, (2^48 < addr < 2^57) ->mmap_end= 2^48
- non-compat, (0 < addr < 2^48) ->mmap_end= 2^39Which seems more likely, based on Charlie comments.
Thanks,
LeoQuoted 30 lines
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.Do I get it wrong?
Maybe I should move this into the optimization part.
Quoted 15 lines
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
--
Best Regards
Guo RenSignature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 84 lines · Leonardo Bras
Quoted 62 lines · Guo Ren
Quoted 61 lines · Leonardo Bras
Quoted 59 lines · Guo Ren
Quoted 51 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 28
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \Quoted 1 line
I don't think I got this change, or how it's connected to the commit msg.
The above is just code simplification; if
STACK_TOP_MAXisTASK_SIZE, thenif ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ mmap_end = STACK_TOP_MAX; \ else if ((_addr) >= VA_USER_SV57) \Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
is equal to:
if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \I am failing to understand exactly how are they equal. I mean, what in your
STACK_TOP_MAXchange made them equal?#define
STACK_TOP_MAXTASK_SIZE
#defineTASK_SIZE(is_compat_task()?TASK_SIZE_32:TASK_SIZE_64)yes, I am aware. Let's do a simple test with the new code and addr = 2^27 (random 32-bit addr) and compat mode.
if ((
_addr) == 0 || (_addr) >=VA_USER_SV57)// Evaluates to false: 2^27 != 0, and is < 2^57 else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) // Evaluates to false: 2^27 < 2^48 else mmap_end = VA_USER_SV39;
Quoted 3 lines
mmap_end=VA_USER_SV39, even incompat_mode.We need the extra
is_compat_task()if we want to return 2^32.
Yes, my stupid, I fell into the wrong logic. Sorry for the noisy part, which should be removed.
Quoted 85 lines
Thanks!
LeoQuoted 19 lines
Quoted 19 lines
See below, the behavior changed:
Quoted 16 lines
Quoted 16 lines
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)Quoted 8 lines
Quoted 6 lines
^
With your change on
STACK_TOP_MAXonly (not changingarch_get_mmap_end), you would have:-
compat_mode& (0 < addr < 2^32) ->mmap_end= 2^32
compat_mode->mmap_end= 2^32This is correct!
Yeah, since you changedSTACK_TOP_MAXto be 2^32 in compat mode, any addr value < 2^32 with compat value will return 2^32. (without the change inarch_get_mmap_end(), that is.)Quoted 46 lines
Quoted 4 lines
- non-compat, addr == 0, or addr > 2^57 ->
mmap_end=TASK_SIZE_64
- non-compat, (2^48 < addr < 2^57) ->mmap_end= 2^48
- non-compat, (0 < addr < 2^48) ->mmap_end= 2^39Quoted 36 lines
Which seems more likely, based on Charlie comments.
Thanks,
LeoQuoted 30 lines
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.Do I get it wrong?
Maybe I should move this into the optimization part.
Quoted 15 lines
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
--
Best Regards
Guo Ren--
Best Regards
Guo Ren
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 85 lines · Guo Ren
Quoted 84 lines · Leonardo Bras
Quoted 62 lines · Guo Ren
Quoted 61 lines · Leonardo Bras
Quoted 59 lines · Guo Ren
Quoted 51 lines · Leonardo Bras
Quoted 6 lines · On Thu, Dec 21, 2023 at 10:46:59AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.ok
Quoted 14 lines
Fixes add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57")Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/processor.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)arch/riscv/include/asm/processor.h +0
-0arch/riscv/include/asm/processor.h line 19
Quoted 5 lines
arch/riscv/include/asm/processor.h +1
-1@@ -16,15 +16,13 @@#ifdef CONFIG_64BIT #define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) -#define STACK_TOP_MAX TASK_SIZE_64 +#define STACK_TOP_MAX TASK_SIZEIt means
STACK_TOP_MAXwill be in 64BIT:
-TASK_SIZE_32if compat_mode=y
-TASK_SIZE_64if compat_mode=nMakes sense for me.
arch/riscv/include/asm/processor.h line 27
Quoted 12 lines
arch/riscv/include/asm/processor.h +1
-3#define arch_get_mmap_end (addr, len, flags) \ ({ \ unsigned long mmap_end; \ typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ - mmap_end = STACK_TOP_MAX; \ - else if ((_addr) >= VA_USER_SV57) \ + if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \ mmap_end = STACK_TOP_MAX; \ else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) \ mmap_end = VA_USER_SV48; \Quoted 1 line
I don't think I got this change, or how it's connected to the commit msg.
The above is just code simplification; if
STACK_TOP_MAXisTASK_SIZE, thenif ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && is_compat_task())) \ mmap_end = STACK_TOP_MAX; \ else if ((_addr) >= VA_USER_SV57) \Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
is equal to:
if ((_addr) == 0 || (_addr) >= VA_USER_SV57) \I am failing to understand exactly how are they equal. I mean, what in your
STACK_TOP_MAXchange made them equal?#define
STACK_TOP_MAXTASK_SIZE
#defineTASK_SIZE(is_compat_task()?TASK_SIZE_32:TASK_SIZE_64)yes, I am aware. Let's do a simple test with the new code and addr = 2^27 (random 32-bit addr) and compat mode.
if ((
_addr) == 0 || (_addr) >=VA_USER_SV57)// Evaluates to false: 2^27 != 0, and is < 2^57 else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= VA_BITS_SV48)) // Evaluates to false: 2^27 < 2^48 else mmap_end = VA_USER_SV39;
Quoted 5 lines
Quoted 3 lines
mmap_end=VA_USER_SV39, even incompat_mode.We need the extra
is_compat_task()if we want to return 2^32.Yes, my stupid, I fell into the wrong logic. Sorry for the noisy part, which should be removed.
Don't worry, I also do stuff like this when I am too focused in the issue :)
Thanks!
Leo
Quoted 92 lines
Quoted 86 lines
Thanks!
LeoQuoted 19 lines
Quoted 19 lines
See below, the behavior changed:
Quoted 16 lines
Quoted 16 lines
Before:
- addr == 0, or addr > 2^57, or compat:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39Now:
- addr == 0, or addr > 2^57:mmap_end=STACK_TOP_MAX
- 2^48 < addr < 2^57:mmap_end= 2^48
- 0 < addr < 2^48 :mmap_end= 2^39IIUC compat mode addr will be < 2^32, so will always have
mmap_end= 2^39 if addr != 0. Is that desireable?
(if not, above change is unneeded)Quoted 8 lines
Quoted 6 lines
^
With your change on
STACK_TOP_MAXonly (not changingarch_get_mmap_end), you would have:-
compat_mode& (0 < addr < 2^32) ->mmap_end= 2^32
compat_mode->mmap_end= 2^32This is correct!
Yeah, since you changedSTACK_TOP_MAXto be 2^32 in compat mode, any addr value < 2^32 with compat value will return 2^32. (without the change inarch_get_mmap_end(), that is.)Quoted 46 lines
Quoted 4 lines
- non-compat, addr == 0, or addr > 2^57 ->
mmap_end=TASK_SIZE_64
- non-compat, (2^48 < addr < 2^57) ->mmap_end= 2^48
- non-compat, (0 < addr < 2^48) ->mmap_end= 2^39Quoted 36 lines
Which seems more likely, based on Charlie comments.
Thanks,
LeoQuoted 30 lines
Quoted 7 lines
Also, unrelated to the change:
- 2^48 < addr < 2^57:mmap_end= 2^48
Is the above correct?
It looks like it should be 2^57 instead, and a new if clause for 2^32 < addr < 2^48 should havemmap_end= 2^48.Do I get it wrong?
Maybe I should move this into the optimization part.
Quoted 15 lines
(I will send an RFC 'fixing' the code the way I am whinking it should look like)
Thanks,
LeoQuoted 3 lines
arch/riscv/include/asm/processor.h +0
-1--2.40.1
--
Best Regards
Guo Ren--
Best Regards
Guo RenSignature · 2 lines
Best Regards Guo Ren
RE: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
In reply to [email protected]From: [email protected] <[email protected]>
Quoted 8 lines
Sent: 21 December 2023 15:47
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.
Why 2G ?
IIRC for 32-bit native x86 the limit is 3G, but in compat mode it is (just under) 4G.
There is a special mmap option (for programs like wine) to limit mmap() to 2G.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Quoted 11 lines · David Laight
From: [email protected] <[email protected]>
Quoted 8 lines
Sent: 21 December 2023 15:47
From: Guo Ren <[email protected]>
When the task is in COMPAT mode, the
arch_get_mmap_endshould be 2GB, notTASK_SIZE_64. TheTASK_SIZEhas containedis_compat_mode()detection, so change the definition ofSTACK_TOP_MAXtoTASK_SIZEdirectly.
Quoted 7 lines
Why 2G ?
IIRC for 32-bit native x86 the limit is 3G, but in compat mode it is (just under) 4G.
There is a special mmap option (for programs like wine) to limit
mmap()to 2G.
The 2G address space seems enough for a small memory scenario, and I agree the compat mode could support 4G, but it should be another feature.
We limited our rv32 applications to under 2GB because we want to leave more address space for the kernel side (Our s64ilp32 kernel needs vmmap stack, kasan ...).
Quoted 7 lines
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Signature · 2 lines
Best Regards Guo Ren
PATCH v2 3/4 riscv: mm: Remove unused TASK_SIZE_MIN
In reply to [email protected]From: Guo Ren <[email protected]>
Remove TASK_SIZE_MIN because it's not used anymore.
--- arch/riscv/include/asm/pgtable.h | 2 -- 1 file changed, 2 deletions(-)
arch/riscv/include/asm/pgtable.h +0 -2
@@ -878,7 +878,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)*/ #ifdef CONFIG_64BIT #define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) -#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT #define TASK_SIZE_32 (_AC(0x80000000, UL))
@@ -890,7 +889,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#else #define TASK_SIZE FIXADDR_START -#define TASK_SIZE_MIN TASK_SIZE#endif #else /* CONFIG_MMU */
Signature · 1 line
2.40.1
Re: [PATCH V2 3/4] riscv: mm: Remove unused TASK_SIZE_MIN
Quoted 33 lines · On Thu, Dec 21, 2023 at 10:47:00AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
Remove
TASK_SIZE_MINbecause it's not used anymore.Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 -- 1 file changed, 2 deletions(-)arch/riscv/include/asm/pgtable.h +0
-2@@ -878,7 +878,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)*/ #ifdef CONFIG_64BIT #define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) -#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT #define TASK_SIZE_32 (_AC(0x80000000, UL))@@ -890,7 +889,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#else #define TASK_SIZE FIXADDR_START -#define TASK_SIZE_MIN TASK_SIZE#endif #else /* CONFIG_MMU */ Signature · 1 line
2.40.1
On torvalds/master:
$git grep TASK_SIZE_MIN arch/loongarch/include/asm/processor.h:23:#define TASK_SIZE_MIN TASK_SIZE arch/loongarch/include/asm/processor.h:36:#define TASK_SIZE_MIN TASK_SIZE32
arch/riscv/include/asm/pgtable.h:881:#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)
arch/riscv/include/asm/pgtable.h:893:#define TASK_SIZE_MIN TASK_SIZE
I can only see definitions, without any usage, so agreed on removing them.
FWIW:
I would also send a patch for loongarch, since they are in the same boat :)
Thanks!
Leo
Re: [PATCH V2 3/4] riscv: mm: Remove unused TASK_SIZE_MIN
Quoted 44 lines · Leonardo Bras
Quoted 31 lines · On Thu, Dec 21, 2023 at 10:47:00AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
Remove
TASK_SIZE_MINbecause it's not used anymore.Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 -- 1 file changed, 2 deletions(-)arch/riscv/include/asm/pgtable.h +0
-3@@ -878,7 +878,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)*/ #ifdef CONFIG_64BIT #define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) -#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT #define TASK_SIZE_32 (_AC(0x80000000, UL))@@ -890,7 +889,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#else #define TASK_SIZE FIXADDR_START -#define TASK_SIZE_MIN TASK_SIZE#endif #else /* CONFIG_MMU */ --Quoted 2 lines
2.40.1
On torvalds/master:
$git grep
TASK_SIZE_MINarch/loongarch/include/asm/processor.h:23:#defineTASK_SIZE_MINTASK_SIZEarch/loongarch/include/asm/processor.h:36:#defineTASK_SIZE_MINTASK_SIZE32
arch/riscv/include/asm/pgtable.h:881:#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)
arch/riscv/include/asm/pgtable.h:893:#defineTASK_SIZE_MINTASK_SIZE
Quoted 4 lines
I can only see definitions, without any usage, so agreed on removing them.
FWIW:
Reviewed-by Leonardo Bras <[email protected]>
Thx
Quoted 2 lines
I would also send a patch for loongarch, since they are in the same boat :)
Eh... I've sent one yesterday together.
https://lore.kernel.org/loongarch/[email protected]/
Quoted 4 lines
Thanks!
Leo
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 3/4] riscv: mm: Remove unused TASK_SIZE_MIN
Quoted 49 lines · Guo Ren
Quoted 44 lines · Leonardo Bras
Quoted 31 lines · On Thu, Dec 21, 2023 at 10:47:00AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
Remove
TASK_SIZE_MINbecause it's not used anymore.Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 2 -- 1 file changed, 2 deletions(-)arch/riscv/include/asm/pgtable.h +0
-3@@ -878,7 +878,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)*/ #ifdef CONFIG_64BIT #define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) -#define TASK_SIZE_MIN (PGDIR_SIZE_L3 * PTRS_PER_PGD / 2)#ifdef CONFIG_COMPAT #define TASK_SIZE_32 (_AC(0x80000000, UL))@@ -890,7 +889,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)#else #define TASK_SIZE FIXADDR_START -#define TASK_SIZE_MIN TASK_SIZE#endif #else /* CONFIG_MMU */ --Quoted 2 lines
2.40.1
On torvalds/master:
$git grep
TASK_SIZE_MINarch/loongarch/include/asm/processor.h:23:#defineTASK_SIZE_MINTASK_SIZEarch/loongarch/include/asm/processor.h:36:#defineTASK_SIZE_MINTASK_SIZE32
arch/riscv/include/asm/pgtable.h:881:#defineTASK_SIZE_MIN(PGDIR_SIZE_L3*PTRS_PER_PGD/ 2)
arch/riscv/include/asm/pgtable.h:893:#defineTASK_SIZE_MINTASK_SIZEQuoted 4 lines
I can only see definitions, without any usage, so agreed on removing them.
FWIW:
Reviewed-by Leonardo Bras <[email protected]>
Quoted 7 lines
Thx
Quoted 2 lines
I would also send a patch for loongarch, since they are in the same boat :)
Eh... I've sent one yesterday together.
Awesome! :)
Quoted 11 lines
Quoted 5 lines
Thanks!
LeoSignature · 2 lines
Best Regards Guo Ren
PATCH v2 4/4 riscv: mm: Optimize TASK_SIZE definition
In reply to [email protected]From: Guo Ren <[email protected]>
Unify the TASK_SIZE definition with VA_BITS for better readability. Add COMPAT mode user address space info in the comment.
--- arch/riscv/include/asm/pgtable.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
arch/riscv/include/asm/pgtable.h +4 -3
@@ -866,6 +866,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)* Note that PGDIR_SIZE must evenly divide TASK_SIZE. * Task size is: * - 0x9fc00000 (~2.5GB) for RV32. +* - 0x80000000 ( 2GB) for RV64 compat mode * - 0x4000000000 ( 256GB) for RV64 using SV39 mmu * - 0x800000000000 ( 128TB) for RV64 using SV48 mmu * - 0x100000000000000 ( 64PB) for RV64 using SV57 mmu
@@ -877,11 +878,11 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)* Similarly for SV57, bits 63–57 must be equal to bit 56. */ #ifdef CONFIG_64BIT -#define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) +#define TASK_SIZE_64 (UL(1) << (VA_BITS - 1))#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL)) -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ +#define TASK_SIZE_32 (UL(1) << (VA_BITS_SV32 - 1)) +#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)#else #define TASK_SIZE TASK_SIZE_64
Signature · 1 line
2.40.1
Re: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
Quoted 24 lines · On Thu, Dec 21, 2023 at 10:47:01AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
Unify the
TASK_SIZEdefinition withVA_BITSfor better readability. Add COMPAT mode user address space info in the comment.Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)arch/riscv/include/asm/pgtable.h +1
-0@@ -866,6 +866,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)* Note that PGDIR_SIZE must evenly divide TASK_SIZE. * Task size is: * - 0x9fc00000 (~2.5GB) for RV32. +* - 0x80000000 ( 2GB) for RV64 compat mode * - 0x4000000000 ( 256GB) for RV64 using SV39 mmu * - 0x800000000000 ( 128TB) for RV64 using SV48 mmu * - 0x100000000000000 ( 64PB) for RV64 using SV57 mmu
arch/riscv/include/asm/pgtable.h static inline pte_t pte_swp_clear_exclusive(pte_t pte) · line 881
Quoted 5 lines
arch/riscv/include/asm/pgtable.h +1
-1@@ -877,11 +878,11 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)* Similarly for SV57, bits 63–57 must be equal to bit 56. */ #ifdef CONFIG_64BIT -#define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) +#define TASK_SIZE_64 (UL(1) << (VA_BITS - 1))
Checked for l5, l4 and l3, and it seems a correct replacement.
arch/riscv/include/asm/pgtable.h static inline pte_t pte_swp_clear_exclusive(pte_t pte) · line 884
Quoted 5 lines
arch/riscv/include/asm/pgtable.h +1
-2#ifdef CONFIG_COMPAT -#define TASK_SIZE_32 (_AC(0x80000000, UL)) -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ +#define TASK_SIZE_32 (UL(1) << (VA_BITS_SV32 - 1))
Oh, much better. Thanks for removing the magic number :)
Quoted 7 lines
arch/riscv/include/asm/pgtable.h +1
-0+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)#else #define TASK_SIZE TASK_SIZE_64Signature · 1 line
2.40.1
That's much more readable IMO now. Thanks!
FWIW:
Re: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
Quoted 35 lines · Leonardo Bras
Quoted 24 lines · On Thu, Dec 21, 2023 at 10:47:01AM -0500, [email protected] wrote:
From: Guo Ren <[email protected]>
Unify the
TASK_SIZEdefinition withVA_BITSfor better readability. Add COMPAT mode user address space info in the comment.Signed-off-by Guo Ren <[email protected]>Signed-off-by Guo Ren <[email protected]>--- arch/riscv/include/asm/pgtable.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)arch/riscv/include/asm/pgtable.h +1
-0@@ -866,6 +866,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)* Note that PGDIR_SIZE must evenly divide TASK_SIZE. * Task size is: * - 0x9fc00000 (~2.5GB) for RV32. +* - 0x80000000 ( 2GB) for RV64 compat mode * - 0x4000000000 ( 256GB) for RV64 using SV39 mmu * - 0x800000000000 ( 128TB) for RV64 using SV48 mmu * - 0x100000000000000 ( 64PB) for RV64 using SV57 mmu arch/riscv/include/asm/pgtable.h static inline pte_t pte_swp_clear_exclusive(pte_t pte) · line 881
Quoted 5 lines
arch/riscv/include/asm/pgtable.h +1
-1@@ -877,11 +878,11 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)* Similarly for SV57, bits 63–57 must be equal to bit 56. */ #ifdef CONFIG_64BIT -#define TASK_SIZE_64 (PGDIR_SIZE * PTRS_PER_PGD / 2) +#define TASK_SIZE_64 (UL(1) << (VA_BITS - 1))Checked for l5, l4 and l3, and it seems a correct replacement.
Quoted 1 line
Quoted 9 lines
arch/riscv/include/asm/pgtable.h static inline pte_t pte_swp_clear_exclusive(pte_t pte) · line 884
Quoted 4 lines
#ifdef
CONFIG_COMPATarch/riscv/include/asm/pgtable.h +1
-2-#define TASK_SIZE_32 (_AC(0x80000000, UL)) -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ +#define TASK_SIZE_32 (UL(1) << (VA_BITS_SV32 - 1))Oh, much better. Thanks for removing the magic number :)
Quoted 2 lines
+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)
I would remove is_compat_task() in the next version because your patch contains that.
Quoted 11 lines
Quoted 5 lines
#else
#defineTASK_SIZETASK_SIZE_64
--
2.40.1That's much more readable IMO now. Thanks!
FWIW:
Reviewed-by Leonardo Bras <[email protected]>
Signature · 2 lines
Best Regards Guo Ren
RE: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
From: Guo Ren
Quoted 1 line
Sent: 22 December 2023 11:25
...
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)I would remove
is_compat_task()in the next version because your patch contains that.
Does TASK_SIZE get used in access_ok() ?
If so the repeated expansion of that 'mess' will slow things down.
OTOH access_ok(ptr, len) can just check (ptr | (ptr + len)) < 0) and rely on the page faults for everything else.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
Hi David,
Quoted 6 lines · David Laight
From: Guo Ren
Quoted 1 line
Sent: 22 December 2023 11:25
...
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)
Quoted 8 lines
Quoted 2 lines
I would remove
is_compat_task()in the next version because your patch contains that.Does
TASK_SIZEget used inaccess_ok()?
If so the repeated expansion of that 'mess' will slow things down.OTOH
access_ok(ptr, len)can just check (ptr | (ptr + len)) < 0) and rely on the page faults for everything else.
I mean, I would remove is_compat_task() optimization. test_thread_flag(TIF_32BIT) -> (is_compat_task() ? Sorry for the bad wording.
Leonardo's new patch series contains the optimization on is_compat_task(), so I canceled mine.
Quoted 6 lines
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Signature · 2 lines
Best Regards Guo Ren
Re: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
In reply to David LaightQuoted 6 lines · David Laight
From: Guo Ren
Quoted 1 line
Sent: 22 December 2023 11:25
...
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)
Quoted 8 lines
Quoted 2 lines
I would remove
is_compat_task()in the next version because your patch contains that.Does
TASK_SIZEget used inaccess_ok()?
If so the repeated expansion of that 'mess' will slow things down.OTOH
access_ok(ptr, len)can just check (ptr | (ptr + len)) < 0) and rely on the page faults for everything else.
Or do you want to discuss the bad side effect of is_compat_task()?
Yes, test_thread_flag(TIF_32BIT) would slow down access_ok(). But if we use TASK_SIZE_MAX, VA_BITS still needs pgtable_l5_enabled, pgtable_l4_enabled detectation for riscv.
It's not only for compat mode, but also Sv39, Sv48, Sv57. All treat TASK_SIZE_MAX as 0x8000000000000000, right? Then:access_ok(ptr, len) can just check (ptr | (ptr + len)) < 0)
It's another feature and does not relate to compat mode.
Quoted 6 lines
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Signature · 2 lines
Best Regards Guo Ren
RE: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
From: Guo Ren
Quoted 23 lines
Sent: 23 December 2023 02:53
Quoted 6 lines · David Laight
From: Guo Ren
Quoted 1 line
Sent: 22 December 2023 11:25
...
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)Quoted 8 lines
Quoted 2 lines
I would remove
is_compat_task()in the next version because your patch contains that.Does
TASK_SIZEget used inaccess_ok()?
If so the repeated expansion of that 'mess' will slow things down.OTOH
access_ok(ptr, len)can just check (ptr | (ptr + len)) < 0) and rely on the page faults for everything else.Or do you want to discuss the bad side effect of
is_compat_task()?Yes,
test_thread_flag(TIF_32BIT)would slow downaccess_ok(). But if we useTASK_SIZE_MAX,VA_BITSstill needspgtable_l5_enabled,pgtable_l4_enableddetectation for riscv.
Quoted 5 lines
It's not only for compat mode, but also Sv39, Sv48, Sv57. All treat
TASK_SIZE_MAXas0x8000000000000000, right? Then:access_ok(ptr, len)can just check (ptr | (ptr + len)) < 0)It's another feature and does not relate to compat mode.
Compat mode just makes it worse...
One possibility would be to save the task's max user address in the task structure itself - that would save all the conditionals at a cost of an extra value in the task structure.
There is also the question of whether a normally 64-bit task can actually make the compat mmap() system call? On x86 that is certainly possible (IIRC wine does it), x86 userspace can flip between 32bit and 63bit mode without a system call.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
Quoted 25 lines · David Laight
From: Guo Ren
Quoted 23 lines
Sent: 23 December 2023 02:53
Quoted 6 lines · David Laight
From: Guo Ren
Quoted 1 line
Sent: 22 December 2023 11:25
...
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
+#define TASK_SIZE (is_compat_task() ? \ TASK_SIZE_32 : TASK_SIZE_64)Quoted 8 lines
Quoted 2 lines
I would remove
is_compat_task()in the next version because your patch contains that.Does
TASK_SIZEget used inaccess_ok()?
If so the repeated expansion of that 'mess' will slow things down.OTOH
access_ok(ptr, len)can just check (ptr | (ptr + len)) < 0) and rely on the page faults for everything else.Or do you want to discuss the bad side effect of
is_compat_task()?Yes,
test_thread_flag(TIF_32BIT)would slow downaccess_ok(). But if we useTASK_SIZE_MAX,VA_BITSstill needspgtable_l5_enabled,pgtable_l4_enableddetectation for riscv.
Quoted 7 lines
Quoted 5 lines
It's not only for compat mode, but also Sv39, Sv48, Sv57. All treat
TASK_SIZE_MAXas0x8000000000000000, right? Then:access_ok(ptr, len)can just check (ptr | (ptr + len)) < 0)It's another feature and does not relate to compat mode.
Compat mode just makes it worse...
It's hard to observe.
Quoted 4 lines
One possibility would be to save the task's max user address in the task structure itself - that would save all the conditionals at a cost of an extra value in the task structure.
It would still cause memory load operation, although it is $tp->xxx. If we want to gain observability benefits, "just check (ptr | (ptr + len)) < 0)" is better.
Quoted 3 lines
There is also the question of whether a normally 64-bit task can actually make the compat
mmap()system call?
No.
Quoted 3 lines
On x86 that is certainly possible (IIRC wine does it), x86 userspace can flip between 32bit and 63bit mode without a system call.
RISC-V can't do that because it needs sstatux.uxl=32/64, which can only be modified in S-mode.
Quoted 6 lines
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Signature · 2 lines
Best Regards Guo Ren
RE: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
From: Guo Ren
Quoted 1 line
Sent: 24 December 2023 01:24
...
Quoted 5 lines
Quoted 3 lines
One possibility would be to save the task's max user address in the task structure itself - that would save all the conditionals at a cost of an extra value in the task structure.
It would still cause memory load operation, although it is $tp->xxx.
All the (mispredicted) branches are likely to cause more of a problem than a load from the current task structure.
Quoted 2 lines
If we want to gain observability benefits, "just check (ptr | (ptr + len)) < 0)" is better.
If you can guarantee a faulting page between user and kernel addresses and assume (check) that the accesses are 'reasonably sequential' then you only need to check the base address.
That is likely hard for 32bit but easier for 64bit (except arm64) because A63 and A62 have to match.
Unless you have some hardware address masking which makes it much more likely that 'random values' will be valid addresses. (Someone remind me why that is a good idea unless the high bits are validated by the hardware.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)