Message ID | 1560850755-3532-1-git-send-email-shihpo.hung@sifive.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | riscv: mm: Fix code comment | expand |
On Tue, 18 Jun 2019 02:39:15 PDT (-0700), shihpo.hung@sifive.com wrote: > From: ShihPo Hung <shihpo.hung@sifive.com> > > Fix the comment since vmalloc_fault doesn't reach > flush_tlb_fix_spurious_fault. > > Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> > Cc: Palmer Dabbelt <palmer@sifive.com> > Cc: Albert Ou <aou@eecs.berkeley.edu> > Cc: Paul Walmsley <paul.walmsley@sifive.com> > Cc: linux-riscv@lists.infradead.org > --- > arch/riscv/mm/fault.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > index 5b72e60..f53ffd7 100644 > --- a/arch/riscv/mm/fault.c > +++ b/arch/riscv/mm/fault.c > @@ -285,9 +285,6 @@ asmlinkage void do_page_fault(struct pt_regs *regs) > * entries, but in RISC-V, SFENCE.VMA specifies an > * ordering constraint, not a cache flush; it is > * necessary even after writing invalid entries. > - * Relying on flush_tlb_fix_spurious_fault would > - * suffice, but the extra traps reduce > - * performance. So, eagerly SFENCE.VMA. > */ > local_flush_tlb_page(addr); Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Thanks!
On Tue, 18 Jun 2019, shihpo.hung@sifive.com wrote: > From: ShihPo Hung <shihpo.hung@sifive.com> > > Fix the comment since vmalloc_fault doesn't reach > flush_tlb_fix_spurious_fault. > > Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> > Cc: Palmer Dabbelt <palmer@sifive.com> > Cc: Albert Ou <aou@eecs.berkeley.edu> > Cc: Paul Walmsley <paul.walmsley@sifive.com> > Cc: linux-riscv@lists.infradead.org Thanks, queued for v5.2-rc with Palmer's Reviewed-by:. - Paul
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c index 5b72e60..f53ffd7 100644 --- a/arch/riscv/mm/fault.c +++ b/arch/riscv/mm/fault.c @@ -285,9 +285,6 @@ asmlinkage void do_page_fault(struct pt_regs *regs) * entries, but in RISC-V, SFENCE.VMA specifies an * ordering constraint, not a cache flush; it is * necessary even after writing invalid entries. - * Relying on flush_tlb_fix_spurious_fault would - * suffice, but the extra traps reduce - * performance. So, eagerly SFENCE.VMA. */ local_flush_tlb_page(addr);