linux-kernel - Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout

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] [day] [month] [year] [list]

Date:   Wed, 17 Feb 2021 13:27:37 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Michal Hocko <mhocko@...e.com>, Mel Gorman <mgorman@...e.de>,
        David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Baoquan He <bhe@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Łukasz Majczak <lma@...ihalf.com>,
        Mike Rapoport <rppt@...ux.ibm.com>, Qian Cai <cai@....pw>,
        "Sarvela, Tomi P" <tomi.p.sarvela@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        stable@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v5 1/1] mm: refactor initialization of struct page for
 holes in memory layout

On 2/16/21 6:49 PM, Mike Rapoport wrote:
> Hi Vlastimil,
> 
> On Tue, Feb 16, 2021 at 05:39:12PM +0100, Vlastimil Babka wrote:
>> 
>> 
>> So, Andrea could you please check if this fixes the original
>> fast_isolate_around() issue for you? With the VM_BUG_ON not removed, DEBUG_VM
>> enabled, no changes to struct page initialization...
>> It relies on pageblock_pfn_to_page as the rest of the compaction code.
> 
> Pardon my ignorance of compaction internals, but does this mean that with
> your patch we'll never call set_pfnblock_flags_mask() for a pfn in a hole?

No it doesn't mean that kind of guarantee. But we will not call it anymore (if
my patch is correct) from a path which we currently know it's doing that and
triggering the VM_BUG_ON. So that's a targetted fix that matches stable backport
criteria. It doesn't contradict your patch as a way to improve mainline, I still
agree it's best long-term if we initialize the struct pages without such
surprises. But I also agree with Michal that there's a risk of replacing one
corner case with another and thus we shouldn't do that as a stable fix.