userfaultfd: clear flag if remap event not enabled
diff mbox series

Message ID 20181210065121.14984-1-peterx@redhat.com
State New
Headers show
Series
  • userfaultfd: clear flag if remap event not enabled
Related show

Commit Message

Peter Xu Dec. 10, 2018, 6:51 a.m. UTC
When the process being tracked do mremap() without
UFFD_FEATURE_EVENT_REMAP on the corresponding tracking uffd file
handle, we should not generate the remap event, and at the same
time we should clear all the uffd flags on the new VMA.  Without
this patch, we can still have the VM_UFFD_MISSING|VM_UFFD_WP
flags on the new VMA even the fault handling process does not
even know the existance of the VMA.

CC: Andrea Arcangeli <aarcange@redhat.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
CC: Kirill A. Shutemov <kirill@shutemov.name>
CC: Hugh Dickins <hughd@google.com>
CC: Pavel Emelyanov <xemul@virtuozzo.com>
CC: Pravin Shedge <pravin.shedge4linux@gmail.com>
CC: linux-mm@kvack.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 fs/userfaultfd.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Mike Rapoport Dec. 10, 2018, 5:51 p.m. UTC | #1
On Mon, Dec 10, 2018 at 02:51:21PM +0800, Peter Xu wrote:
> When the process being tracked do mremap() without
> UFFD_FEATURE_EVENT_REMAP on the corresponding tracking uffd file
> handle, we should not generate the remap event, and at the same
> time we should clear all the uffd flags on the new VMA.  Without
> this patch, we can still have the VM_UFFD_MISSING|VM_UFFD_WP
> flags on the new VMA even the fault handling process does not
> even know the existance of the VMA.
> 
> CC: Andrea Arcangeli <aarcange@redhat.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
> CC: Kirill A. Shutemov <kirill@shutemov.name>
> CC: Hugh Dickins <hughd@google.com>
> CC: Pavel Emelyanov <xemul@virtuozzo.com>
> CC: Pravin Shedge <pravin.shedge4linux@gmail.com>
> CC: linux-mm@kvack.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  fs/userfaultfd.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index cd58939dc977..798ae8a438ff 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -740,6 +740,9 @@ void mremap_userfaultfd_prep(struct vm_area_struct *vma,
>  		vm_ctx->ctx = ctx;
>  		userfaultfd_ctx_get(ctx);
>  		WRITE_ONCE(ctx->mmap_changing, true);
> +	} else if (ctx) {
> +		vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
> +		vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);

My preference would be 

	if (!ctx)
		return;
	
	if (ctx->features & UFFD_FEATURE_EVENT_REMAP) {
		...
	} else {
		...
	}

but I don't feel strongly about it.

I'd appreciate a comment in the code and with it 

Acked-by: Mike Rapoport <rppt@linux.ibm.com>


>  	}
>  }
> 
> -- 
> 2.17.1
>
Andrea Arcangeli Dec. 10, 2018, 8:09 p.m. UTC | #2
Hello,

On Mon, Dec 10, 2018 at 07:51:16PM +0200, Mike Rapoport wrote:
> On Mon, Dec 10, 2018 at 02:51:21PM +0800, Peter Xu wrote:
> > When the process being tracked do mremap() without
> > UFFD_FEATURE_EVENT_REMAP on the corresponding tracking uffd file
> > handle, we should not generate the remap event, and at the same
> > time we should clear all the uffd flags on the new VMA.  Without
> > this patch, we can still have the VM_UFFD_MISSING|VM_UFFD_WP
> > flags on the new VMA even the fault handling process does not
> > even know the existance of the VMA.
> > 
> > CC: Andrea Arcangeli <aarcange@redhat.com>
> > CC: Andrew Morton <akpm@linux-foundation.org>
> > CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > CC: Kirill A. Shutemov <kirill@shutemov.name>
> > CC: Hugh Dickins <hughd@google.com>
> > CC: Pavel Emelyanov <xemul@virtuozzo.com>
> > CC: Pravin Shedge <pravin.shedge4linux@gmail.com>
> > CC: linux-mm@kvack.org
> > CC: linux-kernel@vger.kernel.org
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >  fs/userfaultfd.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > index cd58939dc977..798ae8a438ff 100644
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -740,6 +740,9 @@ void mremap_userfaultfd_prep(struct vm_area_struct *vma,
> >  		vm_ctx->ctx = ctx;
> >  		userfaultfd_ctx_get(ctx);
> >  		WRITE_ONCE(ctx->mmap_changing, true);
> > +	} else if (ctx) {
> > +		vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
> > +		vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);

Great catch Peter!

> 
> My preference would be 
> 
> 	if (!ctx)
> 		return;
> 	
> 	if (ctx->features & UFFD_FEATURE_EVENT_REMAP) {
> 		...
> 	} else {
> 		...
> 	}
> 
> but I don't feel strongly about it.

Yes, it'd look nicer to run a single "ctx not null" check.

> 
> I'd appreciate a comment in the code and with it 
> 
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> 

Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Peter Xu Dec. 11, 2018, 5:16 a.m. UTC | #3
On Mon, Dec 10, 2018 at 03:09:25PM -0500, Andrea Arcangeli wrote:
> Hello,
> 
> On Mon, Dec 10, 2018 at 07:51:16PM +0200, Mike Rapoport wrote:
> > On Mon, Dec 10, 2018 at 02:51:21PM +0800, Peter Xu wrote:
> > > When the process being tracked do mremap() without
> > > UFFD_FEATURE_EVENT_REMAP on the corresponding tracking uffd file
> > > handle, we should not generate the remap event, and at the same
> > > time we should clear all the uffd flags on the new VMA.  Without
> > > this patch, we can still have the VM_UFFD_MISSING|VM_UFFD_WP
> > > flags on the new VMA even the fault handling process does not
> > > even know the existance of the VMA.
> > > 
> > > CC: Andrea Arcangeli <aarcange@redhat.com>
> > > CC: Andrew Morton <akpm@linux-foundation.org>
> > > CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > > CC: Kirill A. Shutemov <kirill@shutemov.name>
> > > CC: Hugh Dickins <hughd@google.com>
> > > CC: Pavel Emelyanov <xemul@virtuozzo.com>
> > > CC: Pravin Shedge <pravin.shedge4linux@gmail.com>
> > > CC: linux-mm@kvack.org
> > > CC: linux-kernel@vger.kernel.org
> > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > ---
> > >  fs/userfaultfd.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > > index cd58939dc977..798ae8a438ff 100644
> > > --- a/fs/userfaultfd.c
> > > +++ b/fs/userfaultfd.c
> > > @@ -740,6 +740,9 @@ void mremap_userfaultfd_prep(struct vm_area_struct *vma,
> > >  		vm_ctx->ctx = ctx;
> > >  		userfaultfd_ctx_get(ctx);
> > >  		WRITE_ONCE(ctx->mmap_changing, true);
> > > +	} else if (ctx) {
> > > +		vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
> > > +		vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);
> 
> Great catch Peter!
> 
> > 
> > My preference would be 
> > 
> > 	if (!ctx)
> > 		return;
> > 	
> > 	if (ctx->features & UFFD_FEATURE_EVENT_REMAP) {
> > 		...
> > 	} else {
> > 		...
> > 	}
> > 
> > but I don't feel strongly about it.
> 
> Yes, it'd look nicer to run a single "ctx not null" check.

I agree.

> 
> > 
> > I'd appreciate a comment in the code and with it 
> > 
> > Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> > 
> 
> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>

Thanks to both!  I'll repost soon.

Regards,

Patch
diff mbox series

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index cd58939dc977..798ae8a438ff 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -740,6 +740,9 @@  void mremap_userfaultfd_prep(struct vm_area_struct *vma,
 		vm_ctx->ctx = ctx;
 		userfaultfd_ctx_get(ctx);
 		WRITE_ONCE(ctx->mmap_changing, true);
+	} else if (ctx) {
+		vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
+		vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);
 	}
 }