All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	David Hildenbrand <david@redhat.com>,
	Hugh Dickins <hughd@google.com>, Maya Gokhale <gokhale2@llnl.gov>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Martin Cracauer <cracauer@cons.org>, Shaohua Li <shli@fb.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Denis Plotnikov <dplotnikov@virtuozzo.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Marty McFadden <mcfadden8@llnl.gov>, Mel Gorman <mgorman@suse.de>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v3 14/28] userfaultfd: wp: handle COW properly for uffd-wp
Date: Tue, 23 Apr 2019 11:34:56 -0400	[thread overview]
Message-ID: <20190423153456.GA3288@redhat.com> (raw)
In-Reply-To: <20190423030030.GA21301@xz-x1>

On Tue, Apr 23, 2019 at 11:00:30AM +0800, Peter Xu wrote:
> On Mon, Apr 22, 2019 at 10:54:02AM -0400, Jerome Glisse wrote:
> > On Mon, Apr 22, 2019 at 08:20:10PM +0800, Peter Xu wrote:
> > > On Fri, Apr 19, 2019 at 11:02:53AM -0400, Jerome Glisse wrote:
> > > 
> > > [...]
> > > 
> > > > > > > +			if (uffd_wp_resolve) {
> > > > > > > +				/* If the fault is resolved already, skip */
> > > > > > > +				if (!pte_uffd_wp(*pte))
> > > > > > > +					continue;
> > > > > > > +				page = vm_normal_page(vma, addr, oldpte);
> > > > > > > +				if (!page || page_mapcount(page) > 1) {
> > > > > > > +					struct vm_fault vmf = {
> > > > > > > +						.vma = vma,
> > > > > > > +						.address = addr & PAGE_MASK,
> > > > > > > +						.page = page,
> > > > > > > +						.orig_pte = oldpte,
> > > > > > > +						.pmd = pmd,
> > > > > > > +						/* pte and ptl not needed */
> > > > > > > +					};
> > > > > > > +					vm_fault_t ret;
> > > > > > > +
> > > > > > > +					if (page)
> > > > > > > +						get_page(page);
> > > > > > > +					arch_leave_lazy_mmu_mode();
> > > > > > > +					pte_unmap_unlock(pte, ptl);
> > > > > > > +					ret = wp_page_copy(&vmf);
> > > > > > > +					/* PTE is changed, or OOM */
> > > > > > > +					if (ret == 0)
> > > > > > > +						/* It's done by others */
> > > > > > > +						continue;
> > > > > > 
> > > > > > This is wrong if ret == 0 you still need to remap the pte before
> > > > > > continuing as otherwise you will go to next pte without the page
> > > > > > table lock for the directory. So 0 case must be handled after
> > > > > > arch_enter_lazy_mmu_mode() below.
> > > > > > 
> > > > > > Sorry i should have catch that in previous review.
> > > > > 
> > > > > My fault to not have noticed it since the very beginning... thanks for
> > > > > spotting that.
> > > > > 
> > > > > I'm squashing below changes into the patch:
> > > > 
> > > > 
> > > > Well thinking of this some more i think you should use do_wp_page() and
> > > > not wp_page_copy() it would avoid bunch of code above and also you are
> > > > not properly handling KSM page or page in the swap cache. Instead of
> > > > duplicating same code that is in do_wp_page() it would be better to call
> > > > it here.
> > > 
> > > Yeah it makes sense to me.  Then here's my plan:
> > > 
> > > - I'll need to drop previous patch "export wp_page_copy" since then
> > >   it'll be not needed
> > > 
> > > - I'll introduce another patch to split current do_wp_page() and
> > >   introduce function "wp_page_copy_cont" (better suggestion on the
> > >   naming would be welcomed) which contains most of the wp handling
> > >   that'll be needed for change_pte_range() in this patch and isolate
> > >   the uffd handling:
> > > 
> > > static vm_fault_t do_wp_page(struct vm_fault *vmf)
> > > 	__releases(vmf->ptl)
> > > {
> > > 	struct vm_area_struct *vma = vmf->vma;
> > > 
> > > 	if (userfaultfd_pte_wp(vma, *vmf->pte)) {
> > > 		pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > 		return handle_userfault(vmf, VM_UFFD_WP);
> > > 	}
> > > 
> > > 	return do_wp_page_cont(vmf);
> > > }
> > > 
> > > Then I can probably use do_wp_page_cont() in this patch.
> > 
> > Instead i would keep the do_wp_page name and do:
> >     static vm_fault_t do_userfaultfd_wp_page(struct vm_fault *vmf) {
> >         ... // what you have above
> >         return do_wp_page(vmf);
> >     }
> > 
> > Naming wise i think it would be better to keep do_wp_page() as
> > is.
> 
> In case I misunderstood... what I've proposed will be simply:
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 64bd8075f054..ab98a1eb4702 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2497,6 +2497,14 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
>                 return handle_userfault(vmf, VM_UFFD_WP);
>         }
> 
> +       return do_wp_page_cont(vmf);
> +}
> +
> +vm_fault_t do_wp_page_cont(struct vm_fault *vmf)
> +       __releases(vmf->ptl)
> +{
> +       struct vm_area_struct *vma = vmf->vma;
> +
>         vmf->page = vm_normal_page(vma, vmf->address, vmf->orig_pte);
>         if (!vmf->page) {
>                 /*
> 
> And the other proposal is:
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 64bd8075f054..a73792127553 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2469,6 +2469,8 @@ static vm_fault_t wp_page_shared(struct vm_fault *vmf)
>         return VM_FAULT_WRITE;
>  }
> 
> +static vm_fault_t do_wp_page(struct vm_fault *vmf);
> +
>  /*
>   * This routine handles present pages, when users try to write
>   * to a shared page. It is done by copying the page to a new address
> @@ -2487,7 +2489,7 @@ static vm_fault_t wp_page_shared(struct vm_fault *vmf)
>   * but allow concurrent faults), with pte both mapped and locked.
>   * We return with mmap_sem still held, but pte unmapped and unlocked.
>   */
> -static vm_fault_t do_wp_page(struct vm_fault *vmf)
> +static vm_fault_t do_userfaultfd_wp_page(struct vm_fault *vmf)
>         __releases(vmf->ptl)
>  {
>         struct vm_area_struct *vma = vmf->vma;
> @@ -2497,6 +2499,14 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
>                 return handle_userfault(vmf, VM_UFFD_WP);
>         }
> 
> +       return do_wp_page(vmf);
> +}
> +
> +static vm_fault_t do_wp_page(struct vm_fault *vmf)
> +       __releases(vmf->ptl)
> +{
> +       struct vm_area_struct *vma = vmf->vma;
> +
>         vmf->page = vm_normal_page(vma, vmf->address, vmf->orig_pte);
>         if (!vmf->page) {
>                 /*
> @@ -2869,7 +2879,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>         }
> 
>         if (vmf->flags & FAULT_FLAG_WRITE) {
> -               ret |= do_wp_page(vmf);
> +               ret |= do_userfaultfd_wp_page(vmf);
>                 if (ret & VM_FAULT_ERROR)
>                         ret &= VM_FAULT_ERROR;
>                 goto out;
> @@ -3831,7 +3841,7 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
>                 goto unlock;
>         if (vmf->flags & FAULT_FLAG_WRITE) {
>                 if (!pte_write(entry))
> -                       return do_wp_page(vmf);
> +                       return do_userfaultfd_wp_page(vmf);
>                 entry = pte_mkdirty(entry);
>         }
>         entry = pte_mkyoung(entry);
> 
> I would prefer the 1st approach since it not only contains fewer lines
> of changes because it does not touch callers, and also the naming in
> the 2nd approach can be a bit confusing (calling
> do_userfaultfd_wp_page in handle_pte_fault may let people think of an
> userfault-only path but actually it covers the general path).  But if
> you really like the 2nd one I can use that too.

Maybe move the userfaultfd code to a small helper, call it first in
call site of do_wp_page() and do_wp_page() if it does not fire ie:

bool do_userfaultfd_wp(struct vm_fault *vmf, int ret)
{
    if (handleuserfault) return true;
    return false;
}

then
     if (vmf->flags & FAULT_FLAG_WRITE) {
            if (do_userfaultfd_wp(vmf, tmp)) {
                ret |= tmp;
            } else
                ret |= do_wp_page(vmf);
            if (ret & VM_FAULT_ERROR)
                ret &= VM_FAULT_ERROR;
            goto out;

and:
    if (vmf->flags & FAULT_FLAG_WRITE) {
        if (!pte_write(entry)) {
            if (do_userfaultfd_wp(vmf, ret))
                return ret;
            else
                return do_wp_page(vmf);
        }

Cheers,
Jérôme

  reply	other threads:[~2019-04-23 15:35 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20  2:06 [PATCH v3 00/28] userfaultfd: write protection support Peter Xu
2019-03-20  2:06 ` [PATCH v3 01/28] mm: gup: rename "nonblocking" to "locked" where proper Peter Xu
2019-03-20  2:06 ` [PATCH v3 02/28] mm: userfault: return VM_FAULT_RETRY on signals Peter Xu
2019-03-20  2:06 ` [PATCH v3 03/28] userfaultfd: don't retake mmap_sem to emulate NOPAGE Peter Xu
2019-03-20  2:06 ` [PATCH v3 04/28] mm: allow VM_FAULT_RETRY for multiple times Peter Xu
2019-04-18 20:11   ` Jerome Glisse
2019-04-19  6:00     ` Peter Xu
2019-03-20  2:06 ` [PATCH v3 05/28] mm: gup: " Peter Xu
2019-03-20  2:06 ` [PATCH v3 06/28] userfaultfd: wp: add helper for writeprotect check Peter Xu
2019-03-20  2:06 ` [PATCH v3 07/28] userfaultfd: wp: hook userfault handler to write protection fault Peter Xu
2019-04-18 20:03   ` Jerome Glisse
2019-03-20  2:06 ` [PATCH v3 08/28] userfaultfd: wp: add WP pagetable tracking to x86 Peter Xu
2019-03-20  2:06 ` [PATCH v3 09/28] userfaultfd: wp: userfaultfd_pte/huge_pmd_wp() helpers Peter Xu
2019-03-20  2:06 ` [PATCH v3 10/28] userfaultfd: wp: add UFFDIO_COPY_MODE_WP Peter Xu
2019-03-20  2:06 ` [PATCH v3 11/28] mm: merge parameters for change_protection() Peter Xu
2019-03-20  2:06 ` [PATCH v3 12/28] userfaultfd: wp: apply _PAGE_UFFD_WP bit Peter Xu
2019-03-20  2:06 ` [PATCH v3 13/28] mm: export wp_page_copy() Peter Xu
2019-03-20  2:06 ` [PATCH v3 14/28] userfaultfd: wp: handle COW properly for uffd-wp Peter Xu
2019-04-18 20:51   ` Jerome Glisse
2019-04-19  6:26     ` Peter Xu
2019-04-19 15:02       ` Jerome Glisse
2019-04-22 12:20         ` Peter Xu
2019-04-22 14:54           ` Jerome Glisse
2019-04-23  3:00             ` Peter Xu
2019-04-23 15:34               ` Jerome Glisse [this message]
2019-04-24  8:38                 ` Peter Xu
2019-03-20  2:06 ` [PATCH v3 15/28] userfaultfd: wp: drop _PAGE_UFFD_WP properly when fork Peter Xu
2019-03-20  2:06 ` [PATCH v3 16/28] userfaultfd: wp: add pmd_swp_*uffd_wp() helpers Peter Xu
2019-03-20  2:06 ` [PATCH v3 17/28] userfaultfd: wp: support swap and page migration Peter Xu
2019-04-18 20:59   ` Jerome Glisse
2019-04-19  7:42     ` Peter Xu
2019-04-19 15:08       ` Jerome Glisse
2019-04-22 12:23         ` Peter Xu
2019-03-20  2:06 ` [PATCH v3 18/28] khugepaged: skip collapse if uffd-wp detected Peter Xu
2019-03-20  2:06 ` [PATCH v3 19/28] userfaultfd: introduce helper vma_find_uffd Peter Xu
2019-03-20  2:06 ` [PATCH v3 20/28] userfaultfd: wp: support write protection for userfault vma range Peter Xu
2019-03-20  2:06 ` [PATCH v3 21/28] userfaultfd: wp: add the writeprotect API to userfaultfd ioctl Peter Xu
2019-03-20  2:06 ` [PATCH v3 22/28] userfaultfd: wp: enabled write protection in userfaultfd API Peter Xu
2019-03-22 21:37   ` Mike Rapoport
2019-03-20  2:06 ` [PATCH v3 23/28] userfaultfd: wp: don't wake up when doing write protect Peter Xu
2019-03-20  2:06 ` [PATCH v3 24/28] userfaultfd: wp: UFFDIO_REGISTER_MODE_WP documentation update Peter Xu
2019-03-22 21:46   ` Mike Rapoport
2019-03-20  2:06 ` [PATCH v3 25/28] userfaultfd: wp: fixup swap entries in change_pte_range Peter Xu
2019-04-18 21:01   ` Jerome Glisse
2019-03-20  2:06 ` [PATCH v3 26/28] userfaultfd: wp: declare _UFFDIO_WRITEPROTECT conditionally Peter Xu
2019-03-22 21:43   ` Mike Rapoport
2019-03-20  2:06 ` [PATCH v3 27/28] userfaultfd: selftests: refactor statistics Peter Xu
2019-03-20  2:06 ` [PATCH v3 28/28] userfaultfd: selftests: add write-protect test Peter Xu
2019-04-09  6:08 ` [PATCH v3 00/28] userfaultfd: write protection support Peter Xu
2019-04-18 21:07   ` Jerome Glisse
2019-04-19  7:53     ` 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=20190423153456.GA3288@redhat.com \
    --to=jglisse@redhat.com \
    --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=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.