From: Leonardo Bras <leobras@redhat.com>
To: guoren@kernel.org
Cc: Leonardo Bras <leobras@redhat.com>,
linux-kernel@vger.kernel.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, alexghiti@rivosinc.com, charlie@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 2/4] riscv: mm: Fixup compat arch_get_mmap_end
Date: Fri, 22 Dec 2023 00:34:56 -0300 [thread overview]
Message-ID: <ZYUD4C1aXWt2oFJo@LeoBras> (raw)
In-Reply-To: <20231221154702.2267684-3-guoren@kernel.org>
On Thu, Dec 21, 2023 at 10:46:59AM -0500, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
>
> 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.
ok
>
> 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/processor.h | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
> index f19f861cda54..1f538fc4448d 100644
> --- a/arch/riscv/include/asm/processor.h
> +++ b/arch/riscv/include/asm/processor.h
> @@ -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.
>
> #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
> --
> 2.40.1
>
next prev parent reply other threads:[~2023-12-22 3:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231221154702.2267684-1-guoren@kernel.org>
2023-12-21 15:46 ` [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure guoren
2023-12-22 1:51 ` Leonardo Bras
2023-12-22 2:57 ` Guo Ren
2023-12-22 3:50 ` Charlie Jenkins
2023-12-22 4:32 ` Leonardo Bras
2023-12-22 7:33 ` 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-22 3:34 ` Leonardo Bras [this message]
2023-12-22 4:04 ` Charlie Jenkins
2023-12-22 4:23 ` Leonardo Bras
2023-12-22 5:42 ` Charlie Jenkins
2023-12-22 8:27 ` Leonardo Bras
2023-12-22 4:36 ` Guo Ren
2023-12-22 4:26 ` Guo Ren
2023-12-22 4:43 ` Leonardo Bras
2023-12-22 4:50 ` Guo Ren
2023-12-22 5:27 ` Leonardo Bras
2023-12-22 7:20 ` Guo Ren
2023-12-22 7:49 ` Leonardo Bras
2023-12-22 8:59 ` David Laight
2023-12-22 9:33 ` Guo Ren
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=ZYUD4C1aXWt2oFJo@LeoBras \
--to=leobras@redhat.com \
--cc=alexghiti@rivosinc.com \
--cc=bjorn@rivosinc.com \
--cc=charlie@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox