Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200715135011.42743-1-kirill.shutemov@linux.intel.com>
 <CAHk-=wh4pB-jRngOjcGxpc8=NPds3jWqJwDMUWC3-OEo4dRiKg@mail.gmail.com> <20200715205428.GA201569@google.com>
In-Reply-To: <20200715205428.GA201569@google.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 15 Jul 2020 14:31:54 -0700
Message-ID: <CAHk-=wg-_Oof43pKUHMk4ySdLwpYi7+shFg+aeV18UP2Akiv8g@mail.gmail.com>
Subject: Re: [PATCHv2] mm: Fix warning in move_normal_pmd()
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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