From: Peter Xu <peterx@redhat.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH v2] mm: userfaultfd: avoid passing an invalid range to vma_merge()
Date: Mon, 15 May 2023 17:39:25 -0400 [thread overview]
Message-ID: <ZGKmjUL5etmvIouh@x1n> (raw)
In-Reply-To: <20230515193232.67552-1-lstoakes@gmail.com>
On Mon, May 15, 2023 at 08:32:32PM +0100, Lorenzo Stoakes wrote:
> As well as fixing the repro described in [1] this also continues to pass
> uffd unit tests.
Side note on testing, not directly relevant to the patch itself..
I'm wondering whether do we have tests somewhere to just test vma
operations on split and merge, then verify it using smap or whatever.
The uffd unit test in this case is probably not gonna trigger anything
because we always mostly register with a whole vma over the testing ranges,
so not immediately helpful.
The trick here is we have quite a few ops that will call vma merge/split in
different ways, but logically we can still category them into: (1) add/del
vmas, or (2) modify vma flags, so at least for case (2) we can have a
framework to cover all the cases (mbind, mprotect, uffd reg/unreg, mlock,
etc.), the difference will be the flags we'll be looking at for different
cases, however how vmas merge/split should be somehow in the same pattern.
--
Peter Xu
next prev parent reply other threads:[~2023-05-15 21:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 19:32 Lorenzo Stoakes
2023-05-15 20:23 ` Liam R. Howlett
2023-05-15 21:27 ` Peter Xu
2023-05-15 22:04 ` Lorenzo Stoakes
2023-05-15 23:07 ` Lorenzo Stoakes
2023-05-16 15:06 ` Peter Xu
2023-05-16 16:49 ` Liam R. Howlett
2023-05-16 20:12 ` Peter Xu
2023-05-16 22:52 ` Liam R. Howlett
2023-05-17 13:50 ` Peter Xu
2023-05-17 22:51 ` Liam R. Howlett
2023-05-18 0:38 ` Peter Xu
2023-05-16 19:25 ` Lorenzo Stoakes
2023-05-16 20:30 ` Peter Xu
2023-05-16 21:01 ` Lorenzo Stoakes
2023-05-16 21:39 ` Peter Xu
2023-05-16 22:15 ` Lorenzo Stoakes
2023-05-16 22:32 ` Peter Xu
2023-05-17 6:21 ` Lorenzo Stoakes
2023-05-16 22:38 ` Liam R. Howlett
2023-05-16 22:51 ` Peter Xu
2023-05-16 22:53 ` Liam R. Howlett
2023-05-15 21:39 ` Peter Xu [this message]
2023-05-15 22:10 ` Lorenzo Stoakes
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=ZGKmjUL5etmvIouh@x1n \
--to=peterx@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mark.rutland@arm.com \
--cc=rppt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox