From: Linus Torvalds <torvalds@linux-foundation.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, Shuah Khan <shuah@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Kirill A Shutemov <kirill@shutemov.name>,
"Liam R. Howlett" <liam.howlett@oracle.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH v2 1/4] mm/mremap: Optimize the start addresses in move_page_tables()
Date: Fri, 19 May 2023 19:34:15 -0700 [thread overview]
Message-ID: <CAHk-=wj9j+puqhe+E-AcG5j-5nP_tQ7DmAcb=Cb6v7n4mpxXjQ@mail.gmail.com> (raw)
In-Reply-To: <CAEXW_YQ4wdGVa5M6jZfi5d-pdJOp1Nu7qTBvWYS=255AnYWZCw@mail.gmail.com>
On Fri, May 19, 2023 at 3:52 PM Joel Fernandes <joel@joelfernandes.org> wrote:
> >
> > I *suspect* that the test is literally just for the stack movement
> > case by execve, where it catches the case where we're doing the
> > movement entirely within the one vma we set up.
>
> Yes that's right, the test is only for the stack movement case. For
> the regular mremap case, I don't think there is a way for it to
> trigger.
So I feel the test is simply redundant.
For the regular mremap case, it never triggers.
And for the stack movement case by execve, I don't think it matters if
you just were to change the logic of the subsequent checks a bit.
In particular, you do this:
/* If the masked address is within vma, there is no prev
mapping of concern. */
if (vma->vm_start <= addr_masked)
return false;
/*
* Attempt to find vma before prev that contains the address.
* On any issue, assume the address is within a previous mapping.
* @mmap write lock is held here, so the lookup is safe.
*/
cur = find_vma_prev(vma->vm_mm, vma->vm_start, &prev);
if (!cur || cur != vma || !prev)
return true;
/* The masked address fell within a previous mapping. */
if (prev->vm_end > addr_masked)
return true;
return false;
And I think that
if (!cur || cur != vma || !prev)
return true;
is actively wrong, because if there is no 'prev', then you should return false.
So I *think* all of the above could just be replaced with this instead:
find_vma_prev(vma->vm_mm, vma->vm_start, &prev);
return prev && prev->vm_end > addr_masked;
because only if we have a 'prev', and the prev is into that masked
address, do we need to avoid doing the masking.
With that simplified test, do you even care about that whole "the
masked address was already in the vma"? Not that I can see.
And we don't even care about the return value of 'find_vma_prev()',
because it had better be 'vma'. We're giving it 'vma->vm_start' as an
address, for chrissake!
So if you *really* wanted to, you could do something like
cur = find_vma_prev(..);
if (WARN_ON_ONCE(cut != vma))
return true;
but even that WARN_ON_ONCE() seems pretty bogus. If it triggers, we
have some serious corruption going on.
So I stil find that whole "vma->vm_start <= addr_masked" test a bit
confusing, since it seems entirely redundant.
Is it just because you wanted to avoid calling "find_vma_prev()" at
all? Maybe just say that in the comment.
Linus
next prev parent reply other threads:[~2023-05-20 2:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-19 19:09 [PATCH v2 0/4] Optimize mremap during mutual alignment within PMD Joel Fernandes (Google)
2023-05-19 19:09 ` [PATCH v2 1/4] mm/mremap: Optimize the start addresses in move_page_tables() Joel Fernandes (Google)
2023-05-19 19:21 ` Linus Torvalds
2023-05-19 22:52 ` Joel Fernandes
2023-05-20 2:34 ` Linus Torvalds [this message]
2023-05-20 3:17 ` Joel Fernandes
2023-05-20 3:56 ` Joel Fernandes
2023-05-20 4:01 ` Linus Torvalds
2023-05-20 4:14 ` Joel Fernandes
2023-05-20 4:22 ` Joel Fernandes
2023-05-20 5:04 ` Joel Fernandes
2023-05-19 19:09 ` [PATCH v2 2/4] selftests: mm: Fix failure case when new remap region was not found Joel Fernandes (Google)
2023-05-19 19:09 ` [PATCH v2 3/4] selftests: mm: Add a test for mutually aligned moves > PMD size Joel Fernandes (Google)
2023-05-19 19:09 ` [PATCH v2 4/4] selftests: mm: Add a test for remapping to area immediately after existing mapping Joel Fernandes (Google)
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='CAHk-=wj9j+puqhe+E-AcG5j-5nP_tQ7DmAcb=Cb6v7n4mpxXjQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=joel@joelfernandes.org \
--cc=kirill@shutemov.name \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mhocko@suse.com \
--cc=paulmck@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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