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

Message-ID: <20210215212440.GA1307762@kernel.org>
Date:   Mon, 15 Feb 2021 23:24:40 +0200
From:   Mike Rapoport <rppt@...nel.org>
To:     Michal Hocko <mhocko@...e.com>
Cc:     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>,
        Vlastimil Babka <vbabka@...e.cz>, 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 Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
> 
> > We can correctly set the zone links for the reserved pages for holes in the
> > middle of a zone based on the architecture constraints and with only the
> > holes in the beginning/end of the memory will be not spanned by any
> > node/zone which in practice does not seem to be a problem as the VM_BUG_ON
> > in set_pfnblock_flags_mask() never triggered on pfn 0.
> 
> I really fail to see what you mean by correct zone/node for a memory
> range which is not associated with any real node.

We know architectural zone constraints, so we can have always have 1:1
match from pfn to zone. Node indeed will be a guess.
  
> > > I am sorry, I haven't followed previous discussions. Has the removal of
> > > the VM_BUG_ON been considered as an immediate workaround?
> > 
> > It was never discussed, but I'm not sure it's a good idea.
> > 
> > Judging by the commit message that introduced the VM_BUG_ON (commit
> > 86051ca5eaf5 ("mm: fix usemap initialization")) there was yet another
> > inconsistency in the memory map that required a special care.
> 
> Can we actually explore that path before adding yet additional
> complexity and potentially a very involved fix for a subtle problem?

This patch was intended as a fix for inconsistency of the memory map that
is the root cause for triggering this VM_BUG_ON and other corner case
problems. 

The previous version [1] is less involved as it does not extend node/zone
spans.

[1] https://lore.kernel.org/lkml/20210130221035.4169-3-rppt@kernel.org
-- 
Sincerely yours,
Mike.