All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charlie Jenkins <charlie@rivosinc.com>
To: Guo Ren <guoren@kernel.org>
Cc: Leonardo Bras <leobras@redhat.com>,
	linux-kernel@vger.kernel.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, alexghiti@rivosinc.com,
	xiao.w.wang@intel.com, david@redhat.com,
	panqinglin2020@iscas.ac.cn, rick.p.edgecombe@intel.com,
	willy@infradead.org, bjorn@rivosinc.com,
	conor.dooley@microchip.com, cleger@rivosinc.com,
	linux-riscv@lists.infradead.org,
	Guo Ren <guoren@linux.alibaba.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Date: Thu, 21 Dec 2023 19:50:27 -0800	[thread overview]
Message-ID: <ZYUHg3kIMYdNSOSr@ghost> (raw)
In-Reply-To: <CAJF2gTT=EQzsuYMHr3FLb82Gi325PqWMEOAzfc6fg=go+gKP_g@mail.gmail.com>

On Fri, Dec 22, 2023 at 10:57:16AM +0800, Guo Ren wrote:
> On Fri, Dec 22, 2023 at 9:51 AM Leonardo Bras <leobras@redhat.com> wrote:
> >
> > Hello Guo Ren,
> >
> > On Thu, Dec 21, 2023 at 10:46:58AM -0500, guoren@kernel.org wrote:
> > > From: Guo Ren <guoren@linux.alibaba.com>
> > >
> > > 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.
> >
> > 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)       -> 0x80000000
> > TASK_SIZE = 0x8000000 - 4k      -> 0x7ffff000
> >
> > IIUC, your suggestion is to make TASK_SIZE = STACK_TOP in 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

> 
> >
> > Then why not:
> > #ifdef CONFIG_COMPAT
> > #define TASK_SIZE_32    STACK_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.
> 
> >
> > With some comments explaining why there is no need to reserve a PAGE_SIZE
> > in the TASK_SIZE_32.
> At first, I wanted to put a invalid page between the user & kernel
> space, but it seems useless.
> 
> >
> > Does that make sense?
> >
> > Thanks!
> > Leo
> >
> > >
> > > 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
> > > ...
> > >
> > > 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
> > >
> >
> 
> 
> -- 
> Best Regards
>  Guo Ren

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Charlie Jenkins <charlie@rivosinc.com>
To: Guo Ren <guoren@kernel.org>
Cc: Leonardo Bras <leobras@redhat.com>,
	linux-kernel@vger.kernel.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, alexghiti@rivosinc.com,
	xiao.w.wang@intel.com, david@redhat.com,
	panqinglin2020@iscas.ac.cn, rick.p.edgecombe@intel.com,
	willy@infradead.org, bjorn@rivosinc.com,
	conor.dooley@microchip.com, cleger@rivosinc.com,
	linux-riscv@lists.infradead.org,
	Guo Ren <guoren@linux.alibaba.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure
Date: Thu, 21 Dec 2023 19:50:27 -0800	[thread overview]
Message-ID: <ZYUHg3kIMYdNSOSr@ghost> (raw)
In-Reply-To: <CAJF2gTT=EQzsuYMHr3FLb82Gi325PqWMEOAzfc6fg=go+gKP_g@mail.gmail.com>

On Fri, Dec 22, 2023 at 10:57:16AM +0800, Guo Ren wrote:
> On Fri, Dec 22, 2023 at 9:51 AM Leonardo Bras <leobras@redhat.com> wrote:
> >
> > Hello Guo Ren,
> >
> > On Thu, Dec 21, 2023 at 10:46:58AM -0500, guoren@kernel.org wrote:
> > > From: Guo Ren <guoren@linux.alibaba.com>
> > >
> > > 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.
> >
> > 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)       -> 0x80000000
> > TASK_SIZE = 0x8000000 - 4k      -> 0x7ffff000
> >
> > IIUC, your suggestion is to make TASK_SIZE = STACK_TOP in 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

> 
> >
> > Then why not:
> > #ifdef CONFIG_COMPAT
> > #define TASK_SIZE_32    STACK_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.
> 
> >
> > With some comments explaining why there is no need to reserve a PAGE_SIZE
> > in the TASK_SIZE_32.
> At first, I wanted to put a invalid page between the user & kernel
> space, but it seems useless.
> 
> >
> > Does that make sense?
> >
> > Thanks!
> > Leo
> >
> > >
> > > 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
> > > ...
> > >
> > > 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
> > >
> >
> 
> 
> -- 
> Best Regards
>  Guo Ren

  reply	other threads:[~2023-12-22  3:50 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-21 15:46 [PATCH V2 0/4] riscv: mm: Fixup & Optimize COMPAT code guoren
2023-12-21 15:46 ` guoren
2023-12-21 15:46 ` [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure guoren
2023-12-21 15:46   ` guoren
2023-12-22  1:51   ` Leonardo Bras
2023-12-22  1:51     ` Leonardo Bras
2023-12-22  2:57     ` Guo Ren
2023-12-22  2:57       ` Guo Ren
2023-12-22  3:50       ` Charlie Jenkins [this message]
2023-12-22  3:50         ` Charlie Jenkins
2023-12-22  4:32         ` Leonardo Bras
2023-12-22  4:32           ` Leonardo Bras
2023-12-22  7:33           ` Guo Ren
2023-12-22  7:33             ` Guo Ren
2023-12-22 10:58         ` Guo Ren
2023-12-22 10:58           ` Guo Ren
2023-12-21 15:46 ` [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end guoren
2023-12-21 15:46   ` guoren
2023-12-22  3:34   ` Leonardo Bras
2023-12-22  3:34     ` Leonardo Bras
2023-12-22  4:04     ` Charlie Jenkins
2023-12-22  4:04       ` Charlie Jenkins
2023-12-22  4:23       ` Leonardo Bras
2023-12-22  4:23         ` Leonardo Bras
2023-12-22  5:42         ` Charlie Jenkins
2023-12-22  5:42           ` Charlie Jenkins
2023-12-22  8:27           ` Leonardo Bras
2023-12-22  8:27             ` Leonardo Bras
2023-12-22  4:36       ` Guo Ren
2023-12-22  4:36         ` Guo Ren
2023-12-22  4:26     ` Guo Ren
2023-12-22  4:26       ` Guo Ren
2023-12-22  4:43       ` Leonardo Bras
2023-12-22  4:43         ` Leonardo Bras
2023-12-22  4:50         ` Guo Ren
2023-12-22  4:50           ` Guo Ren
2023-12-22  5:27           ` Leonardo Bras
2023-12-22  5:27             ` Leonardo Bras
2023-12-22  7:20             ` Guo Ren
2023-12-22  7:20               ` Guo Ren
2023-12-22  7:49               ` Leonardo Bras
2023-12-22  7:49                 ` Leonardo Bras
2023-12-22  8:59   ` David Laight
2023-12-22  8:59     ` David Laight
2023-12-22  9:33     ` Guo Ren
2023-12-22  9:33       ` Guo Ren
2023-12-21 15:47 ` [PATCH V2 3/4] riscv: mm: Remove unused TASK_SIZE_MIN guoren
2023-12-21 15:47   ` guoren
2023-12-22  4:49   ` Leonardo Bras
2023-12-22  4:49     ` Leonardo Bras
2023-12-22  7:16     ` Guo Ren
2023-12-22  7:16       ` Guo Ren
2023-12-22  7:22       ` Leonardo Bras
2023-12-22  7:22         ` Leonardo Bras
2023-12-21 15:47 ` [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition guoren
2023-12-21 15:47   ` guoren
2023-12-22  5:09   ` Leonardo Bras
2023-12-22  5:09     ` Leonardo Bras
2023-12-22 11:25     ` Guo Ren
2023-12-22 11:25       ` Guo Ren
2023-12-22 11:52       ` David Laight
2023-12-22 11:52         ` David Laight
2023-12-23  2:38         ` Guo Ren
2023-12-23  2:38           ` Guo Ren
2023-12-23  2:52         ` Guo Ren
2023-12-23  2:52           ` Guo Ren
2023-12-23 10:31           ` David Laight
2023-12-23 10:31             ` David Laight
2023-12-24  1:24             ` Guo Ren
2023-12-24  1:24               ` Guo Ren
2023-12-24 14:37               ` David Laight
2023-12-24 14:37                 ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZYUHg3kIMYdNSOSr@ghost \
    --to=charlie@rivosinc.com \
    --cc=alexghiti@rivosinc.com \
    --cc=bjorn@rivosinc.com \
    --cc=cleger@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=david@redhat.com \
    --cc=guoren@kernel.org \
    --cc=guoren@linux.alibaba.com \
    --cc=leobras@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=panqinglin2020@iscas.ac.cn \
    --cc=paul.walmsley@sifive.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.org \
    --cc=xiao.w.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.