From: guoren@kernel.org
To: guoren@kernel.org, palmer@rivosinc.com, paul.walmsley@sifive.co,
zong.li@sifive.com, atishp@atishpatra.org, alex@ghiti.fr,
jszhang@kernel.org, bjorn@kernel.org
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org,
Guo Ren <guoren@linux.alibaba.com>
Subject: [PATCH] riscv: pageattr: Fixup synchronization problem between init_mm and active_mm
Date: Thu, 29 Jun 2023 04:20:32 -0400 [thread overview]
Message-ID: <20230629082032.3481237-1-guoren@kernel.org> (raw)
From: Guo Ren <guoren@linux.alibaba.com>
The machine_kexec() uses set_memory_x to add the executable attribute to the
page table entry of control_code_buffer. It only modifies the init_mm but not
the current->active_mm. The current kexec process won't use init_mm directly,
and it depends on minor_pagefault, which is removed by commit 7d3332be011e4
("riscv: mm: Pre-allocate PGD entries for vmalloc/modules area") of 64BIT. So,
when it met pud mapping on an MMU_SV39 machine, it caused the following:
kexec_core: Starting new kernel
Will call new kernel at 00300000 from hart id 0
FDT image at 747c7000
Bye...
Unable to handle kernel paging request at virtual address ffffffda23b0d000
Oops [#1]
Modules linked in:
CPU: 0 PID: 53 Comm: uinit Not tainted 6.4.0-rc6 #15
Hardware name: Sophgo Mango (DT)
epc : 0xffffffda23b0d000
ra : machine_kexec+0xa6/0xb0
epc : ffffffda23b0d000 ra : ffffffff80008272 sp : ffffffc80c173d10
gp : ffffffff8150e1e0 tp : ffffffd9073d2c40 t0 : 0000000000000000
t1 : 0000000000000042 t2 : 6567616d69205444 s0 : ffffffc80c173d50
s1 : ffffffd9076c4800 a0 : ffffffd9076c4800 a1 : 0000000000300000
a2 : 00000000747c7000 a3 : 0000000000000000 a4 : ffffffd800000000
a5 : 0000000000000000 a6 : ffffffd903619c40 a7 : ffffffffffffffff
s2 : ffffffda23b0d000 s3 : 0000000000300000 s4 : 00000000747c7000
s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
s11: 0000003f940001a0 t3 : ffffffff815351af t4 : ffffffff815351af
t5 : ffffffff815351b0 t6 : ffffffc80c173b50
status: 0000000200000100 badaddr: ffffffda23b0d000 cause: 000000000000000c
Yes, Using set_memory_x API after boot has the limitation, and at least we
should synchronize the current->active_mm to fix the problem.
Fixes: d3ab332a5021 ("riscv: add ARCH_HAS_SET_MEMORY support")
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
---
arch/riscv/mm/pageattr.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
index ea3d61de065b..23d169c4ee81 100644
--- a/arch/riscv/mm/pageattr.c
+++ b/arch/riscv/mm/pageattr.c
@@ -123,6 +123,13 @@ static int __set_memory(unsigned long addr, int numpages, pgprot_t set_mask,
&masks);
mmap_write_unlock(&init_mm);
+ if (current->active_mm != &init_mm) {
+ mmap_write_lock(current->active_mm);
+ ret = walk_page_range_novma(current->active_mm, start, end,
+ &pageattr_ops, NULL, &masks);
+ mmap_write_unlock(current->active_mm);
+ }
+
flush_tlb_kernel_range(start, end);
return ret;
--
2.36.1
WARNING: multiple messages have this Message-ID (diff)
From: guoren@kernel.org
To: guoren@kernel.org, palmer@rivosinc.com, paul.walmsley@sifive.co,
zong.li@sifive.com, atishp@atishpatra.org, alex@ghiti.fr,
jszhang@kernel.org, bjorn@kernel.org
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org,
Guo Ren <guoren@linux.alibaba.com>
Subject: [PATCH] riscv: pageattr: Fixup synchronization problem between init_mm and active_mm
Date: Thu, 29 Jun 2023 04:20:32 -0400 [thread overview]
Message-ID: <20230629082032.3481237-1-guoren@kernel.org> (raw)
From: Guo Ren <guoren@linux.alibaba.com>
The machine_kexec() uses set_memory_x to add the executable attribute to the
page table entry of control_code_buffer. It only modifies the init_mm but not
the current->active_mm. The current kexec process won't use init_mm directly,
and it depends on minor_pagefault, which is removed by commit 7d3332be011e4
("riscv: mm: Pre-allocate PGD entries for vmalloc/modules area") of 64BIT. So,
when it met pud mapping on an MMU_SV39 machine, it caused the following:
kexec_core: Starting new kernel
Will call new kernel at 00300000 from hart id 0
FDT image at 747c7000
Bye...
Unable to handle kernel paging request at virtual address ffffffda23b0d000
Oops [#1]
Modules linked in:
CPU: 0 PID: 53 Comm: uinit Not tainted 6.4.0-rc6 #15
Hardware name: Sophgo Mango (DT)
epc : 0xffffffda23b0d000
ra : machine_kexec+0xa6/0xb0
epc : ffffffda23b0d000 ra : ffffffff80008272 sp : ffffffc80c173d10
gp : ffffffff8150e1e0 tp : ffffffd9073d2c40 t0 : 0000000000000000
t1 : 0000000000000042 t2 : 6567616d69205444 s0 : ffffffc80c173d50
s1 : ffffffd9076c4800 a0 : ffffffd9076c4800 a1 : 0000000000300000
a2 : 00000000747c7000 a3 : 0000000000000000 a4 : ffffffd800000000
a5 : 0000000000000000 a6 : ffffffd903619c40 a7 : ffffffffffffffff
s2 : ffffffda23b0d000 s3 : 0000000000300000 s4 : 00000000747c7000
s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
s11: 0000003f940001a0 t3 : ffffffff815351af t4 : ffffffff815351af
t5 : ffffffff815351b0 t6 : ffffffc80c173b50
status: 0000000200000100 badaddr: ffffffda23b0d000 cause: 000000000000000c
Yes, Using set_memory_x API after boot has the limitation, and at least we
should synchronize the current->active_mm to fix the problem.
Fixes: d3ab332a5021 ("riscv: add ARCH_HAS_SET_MEMORY support")
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
---
arch/riscv/mm/pageattr.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
index ea3d61de065b..23d169c4ee81 100644
--- a/arch/riscv/mm/pageattr.c
+++ b/arch/riscv/mm/pageattr.c
@@ -123,6 +123,13 @@ static int __set_memory(unsigned long addr, int numpages, pgprot_t set_mask,
&masks);
mmap_write_unlock(&init_mm);
+ if (current->active_mm != &init_mm) {
+ mmap_write_lock(current->active_mm);
+ ret = walk_page_range_novma(current->active_mm, start, end,
+ &pageattr_ops, NULL, &masks);
+ mmap_write_unlock(current->active_mm);
+ }
+
flush_tlb_kernel_range(start, end);
return ret;
--
2.36.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next reply other threads:[~2023-06-29 8:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 8:20 guoren [this message]
2023-06-29 8:20 ` [PATCH] riscv: pageattr: Fixup synchronization problem between init_mm and active_mm guoren
2023-07-03 10:17 ` Alexandre Ghiti
2023-07-03 10:17 ` Alexandre Ghiti
2023-07-04 2:25 ` Guo Ren
2023-07-04 2:25 ` Guo Ren
2023-07-05 7:00 ` Alexandre Ghiti
2023-07-05 7:00 ` Alexandre Ghiti
2023-07-05 9:15 ` Guo Ren
2023-07-05 9:15 ` Guo Ren
2023-07-05 12:06 ` Alexandre Ghiti
2023-07-05 12:06 ` Alexandre Ghiti
2023-07-09 13:40 ` Guo Ren
2023-07-09 13:40 ` 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=20230629082032.3481237-1-guoren@kernel.org \
--to=guoren@kernel.org \
--cc=alex@ghiti.fr \
--cc=atishp@atishpatra.org \
--cc=bjorn@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=jszhang@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@rivosinc.com \
--cc=paul.walmsley@sifive.co \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.