linux-kernel - Re: WARNING: at mm/mremap.c:211 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHk-=wiU1LR_H4zV6McCKHKJ0unX1zXLTRXfjSEW2HTDjTce0A@mail.gmail.com>
Date:   Sun, 12 Jul 2020 13:38:18 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Naresh Kamboju <naresh.kamboju@...aro.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        William Kucharski <william.kucharski@...cle.com>,
        linux- stable <stable@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...nel.org>,
        lkft-triage@...ts.linaro.org, Chris Down <chris@...isdown.name>,
        Michel Lespinasse <walken@...gle.com>,
        Fan Yang <Fan_Yang@...u.edu.cn>,
        Brian Geffon <bgeffon@...gle.com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>, pugaowei@...il.com,
        Jerome Glisse <jglisse@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Hugh Dickins <hughd@...gle.com>,
        Al Viro <viro@...iv.linux.org.uk>, Tejun Heo <tj@...nel.org>,
        Sasha Levin <sashal@...nel.org>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: WARNING: at mm/mremap.c:211 move_page_tables in i386

On Sun, Jul 12, 2020 at 10:31 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> But I don't see any other way to do it.  It's not like I can put THPs
> in the page cache before fixing the things that won't work.

I agree that sometimes there are bootstrapping issues. Incremental and
explanatory commits are still better than one big commit that
introduces a whole new feature and enables it.

But if at all possible, at least limit the scope of the new feature
first, enabling the simplest possible cases as they become possible so
that there's some incremental testing, and so that bisection can say
"ok, that baseline worked, but then when XYZ happened, things went
sideways".

And even when it's a new feature - if it needs cleanup patches to
other things first, please do that. In fact, please do that as a
completely independent series that goes into a previous kernel release
entirely, so that the cleanup and preparatory patches can be
independently verified by a lot of people who run that _previous_
kernel, so that the baseline of that cleanup phase is something as
stable as possible.

             Linus