From: Linus Torvalds <torvalds@linux-foundation.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
William Kucharski <william.kucharski@oracle.com>
Subject: Re: [PATCHv2] mm: Fix warning in move_normal_pmd()
Date: Wed, 15 Jul 2020 14:31:54 -0700 [thread overview]
Message-ID: <CAHk-=wg-_Oof43pKUHMk4ySdLwpYi7+shFg+aeV18UP2Akiv8g@mail.gmail.com> (raw)
In-Reply-To: <20200715205428.GA201569@google.com>
On Wed, Jul 15, 2020 at 1:54 PM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> Regarding the ADDR_AFTER_NEXT checks, shouldn't you check for:
>
> if (ADDR_AFTER_NEXT(ALIGN(*old_addr + *len, PMD_SIZE), old))
> return;
No, there's even a comment to the effect.
Instead, that ADDR_AFTER_NEXT() aligns the next address _down_ to the
PMD boundary.
Because otherwise, what can happen is:
- you're on an architecture that has a separate address space for users
- you're the next-to-last VMA in that address space,
- you're in the last PMD.
And now "ALIGN(*old_addr + *len, PMD_SIZE)" will wrap, and become 0,
and you think it's ok to move the whole PMD, because it's now smaller
than the start address of the next VMA.
It's _not_ ok, because you'd be moving that next-vma data too.
> and for the len calculation, I did not follow what you did, but I think you
> meant something like this? Does the following reduce to what you did? At
> least this is a bit more readable I think:
>
> *len += (ALIGN(*new_addr + *len, PMD_SIZE) - (*new_addr + *len));
Yes, right you are.
I actually wrote that first (except I added a helper variable for that
"*new_addr + *len" thing), and then I decided it can be simplified.
And simplified it wrong ;)
> Also you did "len +=", it should be "*len +=" in this function.
That's indeed a plain stupid bug ;)
Naresh - don't test that version. The bugs Joel found just make the
math wrong, so it won't work.
The concept was solid, the implementation not so much ;)
Linus
next prev parent reply other threads:[~2020-07-15 21:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 13:50 [PATCHv2] mm: Fix warning in move_normal_pmd() Kirill A. Shutemov
2020-07-15 18:36 ` Linus Torvalds
2020-07-15 20:54 ` Joel Fernandes
2020-07-15 21:13 ` Kirill A. Shutemov
2020-07-15 21:31 ` Linus Torvalds [this message]
2020-07-15 21:43 ` Linus Torvalds
2020-07-15 22:22 ` Kirill A. Shutemov
2020-07-15 22:36 ` Linus Torvalds
2020-07-15 22:57 ` Linus Torvalds
2020-07-15 23:04 ` Linus Torvalds
2020-07-15 23:18 ` Linus Torvalds
2020-07-16 6:37 ` Naresh Kamboju
2020-07-16 7:23 ` Naresh Kamboju
2020-07-16 8:46 ` Kirill A. Shutemov
2020-07-16 8:32 ` Naresh Kamboju
2020-07-16 13:16 ` Kirill A. Shutemov
2020-07-16 17:54 ` Linus Torvalds
2020-07-16 18:47 ` Joel Fernandes
2020-07-15 20:55 ` Kirill A. Shutemov
2020-07-15 21:35 ` Linus Torvalds
2020-07-15 21:51 ` Linus Torvalds
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-=wg-_Oof43pKUHMk4ySdLwpYi7+shFg+aeV18UP2Akiv8g@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=joel@joelfernandes.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naresh.kamboju@linaro.org \
--cc=william.kucharski@oracle.com \
/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).