[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191009074118.GC1039@xz-x1>
Date: Wed, 9 Oct 2019 15:41:18 +0800
From: Peter Xu <peterx@...hat.com>
To: Palmer Dabbelt <palmer@...ive.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, david@...hat.com,
hughd@...gle.com, gokhale2@...l.gov, jglisse@...hat.com,
xemul@...tuozzo.com, hannes@...xchg.org, cracauer@...s.org,
mcfadden8@...l.gov, shli@...com, aarcange@...hat.com,
mike.kravetz@...cle.com, dplotnikov@...tuozzo.com,
rppt@...ux.vnet.ibm.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
mgorman@...e.de, kirill@...temov.name, dgilbert@...hat.com
Subject: Re: [PATCH v4 05/10] mm: Return faster for non-fatal signals in user
mode faults
On Tue, Oct 08, 2019 at 03:43:19PM -0700, Palmer Dabbelt wrote:
> > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> > index deeb820bd855..ea8f301de65b 100644
> > --- a/arch/riscv/mm/fault.c
> > +++ b/arch/riscv/mm/fault.c
> > @@ -111,11 +111,12 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
> > fault = handle_mm_fault(vma, addr, flags);
> >
> > /*
> > - * If we need to retry but a fatal signal is pending, handle the
> > + * If we need to retry but a signal is pending, try to handle the
> > * signal first. We do not need to release the mmap_sem because it
> > * would already be released in __lock_page_or_retry in mm/filemap.c.
> > */
> > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(tsk))
> > + if ((fault & VM_FAULT_RETRY) &&
> > + fault_should_check_signal(user_mode(regs)))
> > return;
> >
> > if (unlikely(fault & VM_FAULT_ERROR)) {
>
> Acked-by: Palmer Dabbelt <palmer@...ive.com> # RISC-V parts
>
> I'm assuming this is going in through some other tree.
Hi, Palmer,
Thanks for reviewing!
There's a new version here, please feel free to have a look too:
https://lore.kernel.org/lkml/20190926093904.5090-1-peterx@redhat.com/
Regards,
--
Peter Xu
Powered by blists - more mailing lists