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: <YCaAHI/rFp1upRLc@dhcp22.suse.cz>
Date:   Fri, 12 Feb 2021 14:18:20 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Mike Rapoport <rppt@...nel.org>,
        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>,
        Mel Gorman <mgorman@...e.de>,
        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 Fri 12-02-21 11:42:15, David Hildenbrand wrote:
> On 12.02.21 11:33, Michal Hocko wrote:
[...]
> > I have to digest this but my first impression is that this is more heavy
> > weight than it needs to. Pfn walkers should normally obey node range at
> > least. The first pfn is usually excluded but I haven't seen real
> 
> We've seen examples where this is not sufficient. Simple example:
> 
> Have your physical memory end within a memory section. Easy via QEMU, just
> do a "-m 4000M". The remaining part of the last section has fake/wrong
> node/zone info.

Does this really matter though. If those pages are reserved then nobody
will touch them regardless of their node/zone ids.

> Hotplug memory. The node/zone gets resized such that PFN walkers might
> stumble over it.
> 
> The basic idea is to make sure that any initialized/"online" pfn belongs to
> exactly one node/zone and that the node/zone spans that PFN.

Yeah, this sounds like a good idea but what is the poper node for hole
between two ranges associated with a different nodes/zones? This will
always be a random number. We should have a clear way to tell "do not
touch those pages" and PageReserved sounds like a good way to tell that.

> > problems with that. The VM_BUG_ON blowing up is really bad but as said
> > above we can simply make it less offensive in presence of reserved pages
> > as those shouldn't reach that path AFAICS normally.
> 
> Andrea tried tried working around if via PG_reserved pages and it resulted
> in quite some ugly code. Andrea also noted that we cannot rely on any random
> page walker to do the right think when it comes to messed up node/zone info.

I am sorry, I haven't followed previous discussions. Has the removal of
the VM_BUG_ON been considered as an immediate workaround?
-- 
Michal Hocko
SUSE Labs