userfaultfd: non-cooperative: selftest: enable REMOVE event test for shmem

Now when madvise(MADV_REMOVE) notifies uffd reader, we should verify
that appliciation actually sees zeros at the removed range.

Link: http://lkml.kernel.org/r/1484814154-1557-4-git-send-email-rppt@linux.vnet.ibm.com
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Mike Rapoport 2017-02-24 14:56:08 -08:00 committed by Linus Torvalds
parent a6bf53eba9
commit 64527f5d54

View File

@ -569,9 +569,9 @@ static int userfaultfd_open(int features)
* part is accessed after mremap. Since hugetlbfs does not support
* mremap, the entire monitored area is accessed in a single pass for
* HUGETLB_TEST.
* The release of the pages currently generates event only for
* The release of the pages currently generates event for shmem and
* anonymous memory (UFFD_EVENT_REMOVE), hence it is not checked
* for hugetlb and shmem.
* for hugetlb.
*/
static int faulting_process(void)
{
@ -610,7 +610,6 @@ static int faulting_process(void)
}
}
#ifndef SHMEM_TEST
if (release_pages(area_dst))
return 1;
@ -618,7 +617,6 @@ static int faulting_process(void)
if (my_bcmp(area_dst + nr * page_size, zeropage, page_size))
fprintf(stderr, "nr %lu is not zero\n", nr), exit(1);
}
#endif /* SHMEM_TEST */
#endif /* HUGETLB_TEST */