All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Xu <peterx@redhat.com>
Cc: Linux-MM <linux-mm@kvack.org>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	David Hildenbrand <david@redhat.com>,
	Hugh Dickins <hughd@google.com>, Maya Gokhale <gokhale2@llnl.gov>,
	Jerome Glisse <jglisse@redhat.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Martin Cracauer <cracauer@cons.org>,
	Denis Plotnikov <dplotnikov@virtuozzo.com>,
	Shaohua Li <shli@fb.com>, Andrea Arcangeli <aarcange@redhat.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Marty McFadden <mcfadden8@llnl.gov>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Mel Gorman <mgorman@suse.de>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v5 02/25] mm: userfault: return VM_FAULT_RETRY on signals
Date: Sat, 22 Jun 2019 11:02:48 -0700	[thread overview]
Message-ID: <CAHk-=wiGphH2UL+To5rASyFoCk6=9bROUkGDWSa_rMu9Kgb0yw@mail.gmail.com> (raw)
In-Reply-To: <20190620022008.19172-3-peterx@redhat.com>

So I still think this all *may* ok, but at a minimum some of the
comments are misleading, and we need more docs on what happens with
normal signals.

I'm picking on just the first one I noticed, but I think there were
other architectures with this too:

On Wed, Jun 19, 2019 at 7:20 PM Peter Xu <peterx@redhat.com> wrote:
>
> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
> index 6836095251ed..3517820aea07 100644
> --- a/arch/arc/mm/fault.c
> +++ b/arch/arc/mm/fault.c
> @@ -139,17 +139,14 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)
>          */
>         fault = handle_mm_fault(vma, address, flags);
>
> -       if (fatal_signal_pending(current)) {
> -
> +       if (unlikely((fault & VM_FAULT_RETRY) && signal_pending(current))) {
> +               if (fatal_signal_pending(current) && !user_mode(regs))
> +                       goto no_context;
>                 /*
>                  * if fault retry, mmap_sem already relinquished by core mm
>                  * so OK to return to user mode (with signal handled first)
>                  */
> -               if (fault & VM_FAULT_RETRY) {
> -                       if (!user_mode(regs))
> -                               goto no_context;
> -                       return;
> -               }
> +               return;
>         }

So note how the end result of this is:

 (a) if a fatal signal is pending, and we're returning to kernel mode,
we do the exception handling

 (b) otherwise, if *any* signal is pending, we'll just return and
retry the page fault

I have nothing against (a), and (b) is likely also ok, but it's worth
noting that (b) happens for kernel returns too. But the comment talks
about returning to user mode.

Is it ok to return to kernel mode when signals are pending? The signal
won't be handled, and we'll just retry the access.

Will we possibly keep retrying forever? When we take the fault again,
we'll set the FAULT_FLAG_ALLOW_RETRY again, so any fault handler that
says "if it allows retry, and signals are pending, just return" would
keep never making any progress, and we'd be stuck taking page faults
in kernel mode forever.

So I think the x86 code sequence is the much safer and more correct
one, because it will actually retry once, and set FAULT_FLAG_TRIED
(and it will clear the "FAULT_FLAG_ALLOW_RETRY" flag - but you'll
remove that clearing later in the series).

> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 46df4c6aae46..dcd7c1393be3 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1463,16 +1463,20 @@ void do_user_addr_fault(struct pt_regs *regs,
>          * that we made any progress. Handle this case first.
>          */
>         if (unlikely(fault & VM_FAULT_RETRY)) {
> +               bool is_user = flags & FAULT_FLAG_USER;
> +
>                 /* Retry at most once */
>                 if (flags & FAULT_FLAG_ALLOW_RETRY) {
>                         flags &= ~FAULT_FLAG_ALLOW_RETRY;
>                         flags |= FAULT_FLAG_TRIED;
> +                       if (is_user && signal_pending(tsk))
> +                               return;
>                         if (!fatal_signal_pending(tsk))
>                                 goto retry;
>                 }
>
>                 /* User mode? Just return to handle the fatal exception */
> -               if (flags & FAULT_FLAG_USER)
> +               if (is_user)
>                         return;
>
>                 /* Not returning to user mode? Handle exceptions or die: */

However, I think the real issue is that it just needs documentation
that a fault handler must not react to signal_pending() as part of the
fault handling itself (ie the VM_FAULT_RETRY can not be *because* of a
non-fatal signal), and there needs to be some guarantee of forward
progress.

At that point the "infinite page faults in kernel mode due to pending
signals" issue goes away. But it's not obvious in this patch, at
least.

               Linus

  reply	other threads:[~2019-06-22 18:03 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-20  2:19 [PATCH v5 00/25] userfaultfd: write protection support Peter Xu
2019-06-20  2:19 ` [PATCH v5 01/25] mm: gup: rename "nonblocking" to "locked" where proper Peter Xu
2019-06-20  2:19 ` [PATCH v5 02/25] mm: userfault: return VM_FAULT_RETRY on signals Peter Xu
2019-06-22 18:02   ` Linus Torvalds [this message]
2019-06-22 18:02     ` Linus Torvalds
2019-06-24  7:42     ` Peter Xu
2019-06-24 13:31       ` Linus Torvalds
2019-06-24 13:31         ` Linus Torvalds
2019-06-25  5:30         ` Peter Xu
2019-06-26  1:59           ` Linus Torvalds
2019-06-26  1:59             ` Linus Torvalds
2019-06-26  7:43             ` Peter Xu
2019-06-20  2:19 ` [PATCH v5 03/25] userfaultfd: don't retake mmap_sem to emulate NOPAGE Peter Xu
2019-06-20  2:19 ` [PATCH v5 04/25] mm: allow VM_FAULT_RETRY for multiple times Peter Xu
2019-06-20  2:19 ` [PATCH v5 05/25] mm: gup: " Peter Xu
2019-06-20  2:19 ` [PATCH v5 06/25] userfaultfd: wp: add helper for writeprotect check Peter Xu
2019-06-20  2:19 ` [PATCH v5 07/25] userfaultfd: wp: hook userfault handler to write protection fault Peter Xu
2019-06-20  2:19 ` [PATCH v5 08/25] userfaultfd: wp: add WP pagetable tracking to x86 Peter Xu
2019-06-20  2:19 ` [PATCH v5 09/25] userfaultfd: wp: userfaultfd_pte/huge_pmd_wp() helpers Peter Xu
2019-06-20  2:19 ` [PATCH v5 10/25] userfaultfd: wp: add UFFDIO_COPY_MODE_WP Peter Xu
2019-06-20  2:19 ` [PATCH v5 11/25] mm: merge parameters for change_protection() Peter Xu
2019-06-20  2:19 ` [PATCH v5 12/25] userfaultfd: wp: apply _PAGE_UFFD_WP bit Peter Xu
2019-06-20  2:19 ` [PATCH v5 13/25] userfaultfd: wp: drop _PAGE_UFFD_WP properly when fork Peter Xu
2019-06-20  2:19 ` [PATCH v5 14/25] userfaultfd: wp: add pmd_swp_*uffd_wp() helpers Peter Xu
2019-06-20  2:19 ` [PATCH v5 15/25] userfaultfd: wp: support swap and page migration Peter Xu
2019-06-20  2:19 ` [PATCH v5 16/25] khugepaged: skip collapse if uffd-wp detected Peter Xu
2019-06-20  2:20 ` [PATCH v5 17/25] userfaultfd: introduce helper vma_find_uffd Peter Xu
2019-06-20  2:20 ` [PATCH v5 18/25] userfaultfd: wp: support write protection for userfault vma range Peter Xu
2019-06-20  2:20 ` [PATCH v5 19/25] userfaultfd: wp: add the writeprotect API to userfaultfd ioctl Peter Xu
2019-06-20  2:20 ` [PATCH v5 20/25] userfaultfd: wp: enabled write protection in userfaultfd API Peter Xu
2019-06-20  2:20 ` [PATCH v5 21/25] userfaultfd: wp: don't wake up when doing write protect Peter Xu
2019-06-20  2:20 ` [PATCH v5 22/25] userfaultfd: wp: UFFDIO_REGISTER_MODE_WP documentation update Peter Xu
2019-06-20  2:20 ` [PATCH v5 23/25] userfaultfd: wp: declare _UFFDIO_WRITEPROTECT conditionally Peter Xu
2019-06-20  2:20 ` [PATCH v5 24/25] userfaultfd: selftests: refactor statistics Peter Xu
2019-06-20  2:20 ` [PATCH v5 25/25] userfaultfd: selftests: add write-protect test Peter Xu
2019-06-23  8:39 ` [PATCH v5 10/25] userfaultfd: wp: add UFFDIO_COPY_MODE_WP Hillf Danton
2020-02-18  3:59 ` [PATCH v5 00/25] userfaultfd: write protection support Bobby Powers
2020-02-18  3:59   ` Bobby Powers
2020-02-18 16:11   ` Peter Xu

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='CAHk-=wiGphH2UL+To5rASyFoCk6=9bROUkGDWSa_rMu9Kgb0yw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=cracauer@cons.org \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=dplotnikov@virtuozzo.com \
    --cc=gokhale2@llnl.gov \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=jglisse@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcfadden8@llnl.gov \
    --cc=mgorman@suse.de \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=shli@fb.com \
    --cc=xemul@virtuozzo.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.