From: Peter Xu <peterx@redhat.com>
To: Audra Mitchell <audra@redhat.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
aarcange@redhat.com, akpm@linux-foundation.org,
rppt@linux.vnet.ibm.com, shli@fb.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
shuah@kernel.org, linux-kselftest@vger.kernel.org,
raquini@redhat.com
Subject: Re: [PATCH v2 3/3] Turn off test_uffdio_wp if CONFIG_PTE_MARKER_UFFD_WP is not configured.
Date: Mon, 24 Jun 2024 10:42:00 -0400 [thread overview]
Message-ID: <ZnmFuAR7yNG_6zp6@x1n> (raw)
In-Reply-To: <Znl6dfM_qbH3hIvH@fedora>
On Mon, Jun 24, 2024 at 09:53:57AM -0400, Audra Mitchell wrote:
> On Fri, Jun 21, 2024 at 05:27:43PM -0400, Peter Xu wrote:
> > On Fri, Jun 21, 2024 at 02:12:24PM -0400, Audra Mitchell wrote:
> > > If CONFIG_PTE_MARKER_UFFD_WP is disabled, then testing with test_uffdio_up
> >
> > Here you're talking about pte markers, then..
> >
> > > enables calling uffdio_regsiter with the flag UFFDIO_REGISTER_MODE_WP. The
> > > kernel ensures in vma_can_userfault() that if CONFIG_PTE_MARKER_UFFD_WP
> > > is disabled, only allow the VM_UFFD_WP on anonymous vmas.
> > >
> > > Signed-off-by: Audra Mitchell <audra@redhat.com>
> > > ---
> > > tools/testing/selftests/mm/uffd-stress.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/tools/testing/selftests/mm/uffd-stress.c b/tools/testing/selftests/mm/uffd-stress.c
> > > index b9b6d858eab8..2601c9dfadd6 100644
> > > --- a/tools/testing/selftests/mm/uffd-stress.c
> > > +++ b/tools/testing/selftests/mm/uffd-stress.c
> > > @@ -419,6 +419,9 @@ static void parse_test_type_arg(const char *raw_type)
> > > test_uffdio_wp = test_uffdio_wp &&
> > > (features & UFFD_FEATURE_PAGEFAULT_FLAG_WP);
> > >
> > > + if (test_type != TEST_ANON && !(features & UFFD_FEATURE_WP_UNPOPULATED))
> > > + test_uffdio_wp = false;
> >
> > ... here you're checking against wp_unpopulated. I'm slightly confused.
> >
> > Are you running this test over shmem/hugetlb when the WP feature isn't
> > supported?
> >
> > I'm wondering whether you're looking for UFFD_FEATURE_WP_HUGETLBFS_SHMEM
> > instead.
>
> I can confirm, its all really confusing... So in userfaultfd_api, we disable
> three features if CONFIG_PTE_MARKER_UFFD_WP is not enabled- including
> UFFD_FEATURE_WP_UNPOPULATED:
>
> #ifndef CONFIG_PTE_MARKER_UFFD_WP
> uffdio_api.features &= ~UFFD_FEATURE_WP_HUGETLBFS_SHMEM;
> uffdio_api.features &= ~UFFD_FEATURE_WP_UNPOPULATED;
> uffdio_api.features &= ~UFFD_FEATURE_WP_ASYNC;
> #endif
>
> If you run the userfaultfd selftests with the run_vmtests script we get
> several failures stemming from trying to call uffdio_regsiter with the flag
> UFFDIO_REGISTER_MODE_WP. However, the kernel ensures in vma_can_userfault()
> that if CONFIG_PTE_MARKER_UFFD_WP is disabled, only allow the VM_UFFD_WP -
> which is set when you pass the UFFDIO_REGISTER_MODE_WP flag - on
> anonymous vmas.
>
> In parse_test_type_arg() I added the features check against
> UFFD_FEATURE_WP_UNPOPULATED as it seemed the most well know feature/flag. I'm
> more than happy to take any suggestions and adapt them if you have any!
There're documents for these features in the headers:
* UFFD_FEATURE_WP_HUGETLBFS_SHMEM indicates that userfaultfd
* write-protection mode is supported on both shmem and hugetlbfs.
*
* UFFD_FEATURE_WP_UNPOPULATED indicates that userfaultfd
* write-protection mode will always apply to unpopulated pages
* (i.e. empty ptes). This will be the default behavior for shmem
* & hugetlbfs, so this flag only affects anonymous memory behavior
* when userfault write-protection mode is registered.
While in this context ("test_type != TEST_ANON") IIUC the accurate feature
to check is UFFD_FEATURE_WP_HUGETLBFS_SHMEM.
In most kernels they should behave the same indeed, but note that since
UNPOPULATED was introduced later than shmem/hugetlb support, it means on
some kernel the result of checking these two features will be different.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-06-24 14:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 18:12 [PATCH v2 1/3] Fix userfaultfd_api to return EINVAL as expected Audra Mitchell
2024-06-21 18:12 ` [PATCH v2 2/3] Update uffd-stress to handle EINVAL for unset config features Audra Mitchell
2024-06-21 21:26 ` Peter Xu
2024-06-21 18:12 ` [PATCH v2 3/3] Turn off test_uffdio_wp if CONFIG_PTE_MARKER_UFFD_WP is not configured Audra Mitchell
2024-06-21 21:27 ` Peter Xu
2024-06-24 13:53 ` Audra Mitchell
2024-06-24 14:42 ` Peter Xu [this message]
2024-06-25 23:05 ` Andrew Morton
2024-06-25 23:55 ` Peter Xu
2024-06-26 12:49 ` Audra Mitchell
2024-06-21 21:25 ` [PATCH v2 1/3] Fix userfaultfd_api to return EINVAL as expected Peter Xu
2024-06-22 1:03 ` Andrew Morton
2024-06-23 15:26 ` Peter Xu
2024-06-24 22:57 ` Andrew Morton
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=ZnmFuAR7yNG_6zp6@x1n \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=audra@redhat.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=raquini@redhat.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=shli@fb.com \
--cc=shuah@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.