From: Peter Xu <peterx@redhat.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
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>,
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: Tue, 16 May 2023 18:51:53 -0400 [thread overview]
Message-ID: <ZGQJCaZiPDjYS8w4@x1n> (raw)
In-Reply-To: <20230516223830.64ege7magdtx3zsr@revolver>
On Tue, May 16, 2023 at 06:38:30PM -0400, Liam R. Howlett wrote:
> > It seems to me what you're trying to explain is we shouldn't handle any
> > split in vma_merge() so we should move cases 4 & 5 out of vma_merge(). If
> > we split first then merge, cases 4 & 5 will become case 2 & 3 after split.
>
> We don't split in case 4 or 5 - we adjust the existing VMA limits. We
> don't actually handle any splits in vma_merge(). I think splitting
> first would change 4 & 5 to 7 & 8? 2 & 3 would require a split and
> munmap, right?
Right, I referenced to the wrong numbers.. 2 & 3 are when CUR (CCCC) is
empty and newly mapped in, if split happened it means CUR (CCCC) exists
which is 7 & 8 correspondingly.
>
> > My question would be: if it worked perfect in the past few years and it
> > looks all good enough, why bother..
>
> I suspect, but it's not clear (like all of this), that the other
> arguments to vma_merge() is ruling out this potential hazard I thought
> existed.
Some more elaborations on this one would be appreciated.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2023-05-16 22:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 19:32 [PATCH v2] mm: userfaultfd: avoid passing an invalid range to vma_merge() 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 [this message]
2023-05-16 22:53 ` Liam R. Howlett
2023-05-15 21:39 ` Peter Xu
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=ZGQJCaZiPDjYS8w4@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 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.