From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Joel Fernandes (Google)" <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>
Subject: Re: [PATCH RFC 1/4] mm/mremap: Optimize the start addresses in move_page_tables()
Date: Wed, 17 May 2023 21:12:07 -0700 [thread overview]
Message-ID: <CAHk-=wi20GzWeK=vUoreX6AXOEmeJKczou1McCOC9JytVO=TQg@mail.gmail.com> (raw)
In-Reply-To: <20230518021825.712742-2-joel@joelfernandes.org>
On Wed, May 17, 2023 at 7:18 PM Joel Fernandes (Google)
<joel@joelfernandes.org> wrote:
>
> This warning will only trigger when there is mutual alignment in the
> move operation. A solution, as suggested by Linus Torvalds [2], is to
> initiate the copy process at the PMD level whenever such alignment is
> present.
So this patch is actually simpler than I thought it would be.
But I'm a bit nervous about it. In particular, it ends doing
old_end = old_addr + len;
... expand old_addr/new_addr down to the pmd boundary ..
return len + old_addr - old_end; /* how much done */
doesn't that return value end up being nonsensical now?
In particular, I think it can return a *negative* value, because of
how old_addr was moved down, and the "now much done" might indeed be
"negative" in the sense that it failed the move even "before" the
original starting point.
And that negative value then ends up being a large positive one as an
"unsigned long", of course.
So I get the feeling that it wants something like
if (old_addr + len < old_end)
return 0;
there at the end.
But maybe there is something in there that guarantees that that case
never happens. I didn't think too deeply about it, I just felt this
looked odd.
Linus
next prev parent reply other threads:[~2023-05-18 4:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 2:18 [PATCH RFC 0/4] Optimize mremap during mutual alignment within PMD Joel Fernandes (Google)
2023-05-18 2:18 ` [PATCH RFC 1/4] mm/mremap: Optimize the start addresses in move_page_tables() Joel Fernandes (Google)
2023-05-18 4:12 ` Linus Torvalds [this message]
2023-05-18 14:44 ` Joel Fernandes
2023-05-18 2:18 ` [PATCH RFC 2/4] selftests: mm: Fix failure case when new remap region was not found Joel Fernandes (Google)
2023-05-18 2:18 ` [PATCH RFC 3/4] selftests: mm: Add a test for mutually aligned moves > PMD size Joel Fernandes (Google)
2023-05-18 2:18 ` [PATCH RFC 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-=wi20GzWeK=vUoreX6AXOEmeJKczou1McCOC9JytVO=TQg@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=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