From: Jann Horn <jannh@google.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org,
willy@infradead.org, hughd@google.com,
lorenzo.stoakes@oracle.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/mremap: Fix move_normal_pmd/retract_page_tables race
Date: Wed, 9 Oct 2024 02:49:26 +0200 [thread overview]
Message-ID: <CAG48ez1ZMo0K0JU321vs0ovXXF2giMvVo14AxNDPzgpGMGZpDA@mail.gmail.com> (raw)
In-Reply-To: <CAEXW_YSxcPJG8SrsrgXGQVOYOMwHRHMrEcB7Rp2ya0Zsn9ED1g@mail.gmail.com>
On Wed, Oct 9, 2024 at 1:58 AM Joel Fernandes <joel@joelfernandes.org> wrote:
> On Mon, Oct 7, 2024 at 5:42 PM Jann Horn <jannh@google.com> wrote:
> Not to overthink it, but do you have any insight into why copy_vma()
> only requires the rmap lock under this condition?
>
> *need_rmap_locks = (new_vma->vm_pgoff <= vma->vm_pgoff);
>
> Could a collapse still occur when need_rmap_locks is false,
> potentially triggering the bug you described? My assumption is no, but
> I wanted to double-check.
Ah, that code is a bit confusing. There are actually two circumstances
under which we take rmap locks, and that condition only captures (part
of) the first one:
1. when we might move PTEs against rmap traversal order (we need the
lock so that concurrent rmap traversal can't miss the PTEs)
2. when we move page tables (otherwise concurrent rmap traversal could
race with page table changes)
If you look at the four callsites of move_pgt_entry(), you can see
that its parameter "need_rmap_locks" sometimes comes from the caller's
"need_rmap_locks" variable (in the HPAGE_PUD and HPAGE_PMD cases), but
other times it is just hardcoded to true (in the NORMAL_PUD and
NORMAL_PMD cases).
So move_normal_pmd() always holds rmap locks.
(This code would probably be a bit clearer if we moved the rmap
locking into the helpers move_{normal,huge}_{pmd,pud} and got rid of
the helper move_pgt_entry()...)
(Also, note that when undoing the PTE moves with the second
move_page_tables() call, the "need_rmap_locks" parameter to
move_page_tables() is hardcoded to true.)
> The patch looks good to me overall. I was also curious if
> move_normal_pud() would require a similar change, though I’m inclined
> to think that path doesn't lead to a bug.
Yeah, there is no path that would remove PUD entries pointing to page
tables through the rmap, that's a special PMD entry thing. (Well, at
least not in non-hugetlb code, I haven't looked at hugetlb in a long
time - but hugetlb has an entirely separate codepath for moving page
tables, move_hugetlb_page_tables().)
next prev parent reply other threads:[~2024-10-09 0:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 21:42 [PATCH] mm/mremap: Fix move_normal_pmd/retract_page_tables race Jann Horn
2024-10-08 3:53 ` Qi Zheng
2024-10-08 7:52 ` David Hildenbrand
2024-10-08 7:58 ` Qi Zheng
2024-10-08 8:21 ` David Hildenbrand
2024-10-08 7:50 ` David Hildenbrand
2024-10-08 23:58 ` Joel Fernandes
2024-10-09 0:49 ` Jann Horn [this message]
2024-10-09 1:46 ` Joel Fernandes
2024-10-09 14:44 ` 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=CAG48ez1ZMo0K0JU321vs0ovXXF2giMvVo14AxNDPzgpGMGZpDA@mail.gmail.com \
--to=jannh@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).