On Sat, Dec 23, 2023 at 11:07:29AM +0800, Guo Ren wrote:
On Sat, Dec 23, 2023 at 10:58 AM Leonardo Bras leobras@redhat.com wrote:
On Fri, Dec 22, 2023 at 06:57:00AM -0500, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
In COMPAT mode, the STACK_TOP is DEFAULT_MAP_WINDOW (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 ...
Increase the TASK_SIZE to cover STACK_TOP.
Cc: stable@vger.kernel.org Fixes: add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") Signed-off-by: Guo Ren guoren@linux.alibaba.com Signed-off-by: Guo Ren guoren@kernel.org
arch/riscv/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index ab00235b018f..74ffb2178f54 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -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
I am not really involved in the issue this is solving, so I have no technical opinion on the solution.
IIUC there should always be (TASK_SIZE >= STACK_TOP), so by itself this is fixing an issue.
I have reviewed the code and it does exactly as stated into the commit message, so FWIW: Reviewed-by: Leonardo Bras leobras@redhat.com
Thx,
I found this problem because it can't boot my rv32 buildroot-rootfs in v6.6. But it's okay in v6.5. So I used git bisect and found commit: add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57"), which caused that.
Ping Charlie, I hope it can be fixed in the v6.6 long-term version.
I have looked at this more I do agree that this change makes sense. I was thinking that it was valid to have STACK_TOP that was greater than TASK_SIZE but I am no longer convinced that is true. Thank you for looking into this.
Reviewed-by: Charlie Jenkins charlie@rivosinc.com
-- Best Regards Guo Ren