* [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
@ 2023-02-24 10:40 ` Dylan Jhong
0 siblings, 0 replies; 6+ messages in thread
From: Dylan Jhong @ 2023-02-24 10:40 UTC (permalink / raw
To: linux-riscv, linux-kernel
Cc: liushixin2, x5710999x, bjorn, abrestic, peterx, hanchuanhua,
apopple, hca, aou, palmer, paul.walmsley, tim609, peterlin,
ycliang, Dylan Jhong
RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
vmalloc_fault() assumes that the vmalloc range is limited to pte
mappings. Add huge page support to complete the vmalloc_fault()
function.
Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
Signed-off-by: Dylan Jhong <dylan@andestech.com>
---
arch/riscv/mm/fault.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index eb0774d9c03b..4b9953b47d81 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
no_context(regs, addr);
return;
}
+ if (pud_leaf(*pud_k))
+ goto flush_tlb;
/*
* Since the vmalloc area is global, it is unnecessary
@@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
no_context(regs, addr);
return;
}
+ if (pmd_leaf(*pmd_k))
+ goto flush_tlb;
/*
* Make sure the actual PTE exists as well to
@@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
* ordering constraint, not a cache flush; it is
* necessary even after writing invalid entries.
*/
+flush_tlb:
local_flush_tlb_page(addr);
}
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
@ 2023-02-24 10:40 ` Dylan Jhong
0 siblings, 0 replies; 6+ messages in thread
From: Dylan Jhong @ 2023-02-24 10:40 UTC (permalink / raw
To: linux-riscv, linux-kernel
Cc: liushixin2, x5710999x, bjorn, abrestic, peterx, hanchuanhua,
apopple, hca, aou, palmer, paul.walmsley, tim609, peterlin,
ycliang, Dylan Jhong
RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
vmalloc_fault() assumes that the vmalloc range is limited to pte
mappings. Add huge page support to complete the vmalloc_fault()
function.
Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
Signed-off-by: Dylan Jhong <dylan@andestech.com>
---
arch/riscv/mm/fault.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index eb0774d9c03b..4b9953b47d81 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
no_context(regs, addr);
return;
}
+ if (pud_leaf(*pud_k))
+ goto flush_tlb;
/*
* Since the vmalloc area is global, it is unnecessary
@@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
no_context(regs, addr);
return;
}
+ if (pmd_leaf(*pmd_k))
+ goto flush_tlb;
/*
* Make sure the actual PTE exists as well to
@@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
* ordering constraint, not a cache flush; it is
* necessary even after writing invalid entries.
*/
+flush_tlb:
local_flush_tlb_page(addr);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
2023-02-24 10:40 ` Dylan Jhong
@ 2023-02-24 12:47 ` Alexandre Ghiti
-1 siblings, 0 replies; 6+ messages in thread
From: Alexandre Ghiti @ 2023-02-24 12:47 UTC (permalink / raw
To: Dylan Jhong, linux-riscv, linux-kernel
Cc: liushixin2, x5710999x, bjorn, abrestic, peterx, hanchuanhua,
apopple, hca, aou, palmer, paul.walmsley, tim609, peterlin,
ycliang
Hi Dylan,
On 2/24/23 11:40, Dylan Jhong wrote:
> RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
> vmalloc_fault() assumes that the vmalloc range is limited to pte
> mappings. Add huge page support to complete the vmalloc_fault()
> function.
>
> Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
>
> Signed-off-by: Dylan Jhong <dylan@andestech.com>
> ---
> arch/riscv/mm/fault.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index eb0774d9c03b..4b9953b47d81 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> no_context(regs, addr);
> return;
> }
> + if (pud_leaf(*pud_k))
> + goto flush_tlb;
>
> /*
> * Since the vmalloc area is global, it is unnecessary
> @@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> no_context(regs, addr);
> return;
> }
> + if (pmd_leaf(*pmd_k))
> + goto flush_tlb;
>
> /*
> * Make sure the actual PTE exists as well to
> @@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> * ordering constraint, not a cache flush; it is
> * necessary even after writing invalid entries.
> */
> +flush_tlb:
> local_flush_tlb_page(addr);
> }
>
This looks good to me, you can add:
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
One question: how did you encounter this bug?
Thanks,
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
@ 2023-02-24 12:47 ` Alexandre Ghiti
0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Ghiti @ 2023-02-24 12:47 UTC (permalink / raw
To: Dylan Jhong, linux-riscv, linux-kernel
Cc: liushixin2, x5710999x, bjorn, abrestic, peterx, hanchuanhua,
apopple, hca, aou, palmer, paul.walmsley, tim609, peterlin,
ycliang
Hi Dylan,
On 2/24/23 11:40, Dylan Jhong wrote:
> RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
> vmalloc_fault() assumes that the vmalloc range is limited to pte
> mappings. Add huge page support to complete the vmalloc_fault()
> function.
>
> Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
>
> Signed-off-by: Dylan Jhong <dylan@andestech.com>
> ---
> arch/riscv/mm/fault.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index eb0774d9c03b..4b9953b47d81 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> no_context(regs, addr);
> return;
> }
> + if (pud_leaf(*pud_k))
> + goto flush_tlb;
>
> /*
> * Since the vmalloc area is global, it is unnecessary
> @@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> no_context(regs, addr);
> return;
> }
> + if (pmd_leaf(*pmd_k))
> + goto flush_tlb;
>
> /*
> * Make sure the actual PTE exists as well to
> @@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> * ordering constraint, not a cache flush; it is
> * necessary even after writing invalid entries.
> */
> +flush_tlb:
> local_flush_tlb_page(addr);
> }
>
This looks good to me, you can add:
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
One question: how did you encounter this bug?
Thanks,
Alex
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
2023-02-24 12:47 ` Alexandre Ghiti
@ 2023-03-01 11:17 ` Dylan Jhong
-1 siblings, 0 replies; 6+ messages in thread
From: Dylan Jhong @ 2023-03-01 11:17 UTC (permalink / raw
To: Alexandre Ghiti
Cc: linux-riscv, linux-kernel, liushixin2, x5710999x, bjorn, abrestic,
peterx, hanchuanhua, apopple, hca, aou, palmer, paul.walmsley,
tim609, peterlin, ycliang
On Fri, Feb 24, 2023 at 01:47:20PM +0100, Alexandre Ghiti wrote:
> Hi Dylan,
>
> On 2/24/23 11:40, Dylan Jhong wrote:
> > RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
> > vmalloc_fault() assumes that the vmalloc range is limited to pte
> > mappings. Add huge page support to complete the vmalloc_fault()
> > function.
> >
> > Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
> >
> > Signed-off-by: Dylan Jhong <dylan@andestech.com>
> > ---
> > arch/riscv/mm/fault.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> > index eb0774d9c03b..4b9953b47d81 100644
> > --- a/arch/riscv/mm/fault.c
> > +++ b/arch/riscv/mm/fault.c
> > @@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> > no_context(regs, addr);
> > return;
> > }
> > + if (pud_leaf(*pud_k))
> > + goto flush_tlb;
> > /*
> > * Since the vmalloc area is global, it is unnecessary
> > @@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> > no_context(regs, addr);
> > return;
> > }
> > + if (pmd_leaf(*pmd_k))
> > + goto flush_tlb;
> > /*
> > * Make sure the actual PTE exists as well to
> > @@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> > * ordering constraint, not a cache flush; it is
> > * necessary even after writing invalid entries.
> > */
> > +flush_tlb:
> > local_flush_tlb_page(addr);
> > }
>
>
> This looks good to me, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>
> One question: how did you encounter this bug?
>
> Thanks,
>
> Alex
>
Hi Alex,
>>> One question: how did you encounter this bug?
This bug is caused by the combination of out-of-order excutiuon and ioremap().
The OoO excution will try to access the VA that is given by ioremap() and record
a page fault in TLB before the mapping is created in ioremap(). When the CPU
really accesses the VA after ioremap(), the CPU will trigger page fault because
of the TLB already has the VA mapping.
We hope that the vmalloc_fault() in page fault handler will trigger sfence.vma
to invalidate the TLB[1]. But since we do not support the huge page in vmalloc_fault(),
we encountered the nested page faults in vmalloc_fault() while forcing the pmd/pud
huge pages to resolve pte entry. This is the reason I send this patch.
ref:
[1]: https://patchwork.kernel.org/project/linux-riscv/patch/20210412000531.12249-1-liu@jiuyang.me/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] RISC-V: mm: Support huge page in vmalloc_fault()
@ 2023-03-01 11:17 ` Dylan Jhong
0 siblings, 0 replies; 6+ messages in thread
From: Dylan Jhong @ 2023-03-01 11:17 UTC (permalink / raw
To: Alexandre Ghiti
Cc: linux-riscv, linux-kernel, liushixin2, x5710999x, bjorn, abrestic,
peterx, hanchuanhua, apopple, hca, aou, palmer, paul.walmsley,
tim609, peterlin, ycliang
On Fri, Feb 24, 2023 at 01:47:20PM +0100, Alexandre Ghiti wrote:
> Hi Dylan,
>
> On 2/24/23 11:40, Dylan Jhong wrote:
> > RISC-V supports ioremap() with huge page (pud/pmd) mapping, but
> > vmalloc_fault() assumes that the vmalloc range is limited to pte
> > mappings. Add huge page support to complete the vmalloc_fault()
> > function.
> >
> > Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT")
> >
> > Signed-off-by: Dylan Jhong <dylan@andestech.com>
> > ---
> > arch/riscv/mm/fault.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> > index eb0774d9c03b..4b9953b47d81 100644
> > --- a/arch/riscv/mm/fault.c
> > +++ b/arch/riscv/mm/fault.c
> > @@ -143,6 +143,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> > no_context(regs, addr);
> > return;
> > }
> > + if (pud_leaf(*pud_k))
> > + goto flush_tlb;
> > /*
> > * Since the vmalloc area is global, it is unnecessary
> > @@ -153,6 +155,8 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> > no_context(regs, addr);
> > return;
> > }
> > + if (pmd_leaf(*pmd_k))
> > + goto flush_tlb;
> > /*
> > * Make sure the actual PTE exists as well to
> > @@ -172,6 +176,7 @@ static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long a
> > * ordering constraint, not a cache flush; it is
> > * necessary even after writing invalid entries.
> > */
> > +flush_tlb:
> > local_flush_tlb_page(addr);
> > }
>
>
> This looks good to me, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>
> One question: how did you encounter this bug?
>
> Thanks,
>
> Alex
>
Hi Alex,
>>> One question: how did you encounter this bug?
This bug is caused by the combination of out-of-order excutiuon and ioremap().
The OoO excution will try to access the VA that is given by ioremap() and record
a page fault in TLB before the mapping is created in ioremap(). When the CPU
really accesses the VA after ioremap(), the CPU will trigger page fault because
of the TLB already has the VA mapping.
We hope that the vmalloc_fault() in page fault handler will trigger sfence.vma
to invalidate the TLB[1]. But since we do not support the huge page in vmalloc_fault(),
we encountered the nested page faults in vmalloc_fault() while forcing the pmd/pud
huge pages to resolve pte entry. This is the reason I send this patch.
ref:
[1]: https://patchwork.kernel.org/project/linux-riscv/patch/20210412000531.12249-1-liu@jiuyang.me/
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-03-01 11:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-02-24 10:40 [PATCH] RISC-V: mm: Support huge page in vmalloc_fault() Dylan Jhong
2023-02-24 10:40 ` Dylan Jhong
2023-02-24 12:47 ` Alexandre Ghiti
2023-02-24 12:47 ` Alexandre Ghiti
2023-03-01 11:17 ` Dylan Jhong
2023-03-01 11:17 ` Dylan Jhong
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.