linux-kernel - Re: [PATCH RFC 1/4] mm/mremap: Optimize the start addresses in move_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wi20GzWeK=vUoreX6AXOEmeJKczou1McCOC9JytVO=TQg@mail.gmail.com>
Date:   Wed, 17 May 2023 21:12:07 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Joel Fernandes (Google)" <joel@...lfernandes.org>
Cc:     linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-mm@...ck.org, Shuah Khan <shuah@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Michal Hocko <mhocko@...e.com>,
        Lorenzo Stoakes <lstoakes@...il.com>,
        Kirill A Shutemov <kirill@...temov.name>,
        "Liam R. Howlett" <liam.howlett@...cle.com>,
        "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH RFC 1/4] mm/mremap: Optimize the start addresses in move_page_tables()

On Wed, May 17, 2023 at 7:18 PM Joel Fernandes (Google)
<joel@...lfernandes.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