linux-kernel - Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock

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: <20201126104353.GR123287@linux.ibm.com>
Date:   Thu, 26 Nov 2020 12:43:53 +0200
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>,
        David Hildenbrand <david@...hat.com>,
        Mel Gorman <mgorman@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        Qian Cai <cai@....pw>, Michal Hocko <mhocko@...nel.org>,
        linux-kernel@...r.kernel.org, Baoquan He <bhe@...hat.com>
Subject: Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set
 pageblock_skip on reserved pages

On Wed, Nov 25, 2020 at 10:40:20PM -0500, Andrea Arcangeli wrote:
> On Wed, Nov 25, 2020 at 12:34:41AM -0500, Andrea Arcangeli wrote:
> 
> Summary: both old code (missing PG_reserved) and the current code
> (leaving the page struct uninitialized and with wrong nodeid/nid) look
> wrong.
> 
> Overall this brings more questions:
> 
> - why memblock.reserved exists and isn't automatically calculated as
>   inversion of memblock.memory? (or if you prefer: why is the above
>   call to memblock_reserve needed to initialize the memory holes?)

memblock.reserved represents memory areas that were allocated before
page allocator is up. This could be memory reported by firmware as
resrved, kernel image, initrd, and any memory kernel allocates before
page allocator is ready.

> - why there's no initialization of the memblock.reserved regions given
>   they exists, was it just an oversight? (this one is fixed by Mike's
>   patch, although I wish it was possible to drop the function
>   memblock_reserve instead)

It was an oversight when I posted
73a6e474cb376921a311786652782155eac2fdf0. I overlooked the fact that x86
does not consider memory allocated by firmware as memory and only parts
of it are considred reserved.

> - what can we do instead of setting the uninitialized nodeid/nid to
>   0,0 and to reliably detect at boot if some page structure within
>   zones (but ideally also outside the zone boundary for any pfn where
>   pfn_valid returns true) is left uninitialized, as it is happening
>   currently on the e820 type 20 range?

I think that we need to fix the e820 and memblock interaction at the
first place. The "non-RAM" holes reported as various types other than
E820_TYPE_RAM are actually seem to be "RAM that firmware grabbed for
itself", so they should be seen by the system as such, like in all other
architectures.
For the regions that cannot be mapped, like those on HPE UV (was it
SGI?) systems, we have MEMBLOCK_NOMAP exactly for that purpose.

Once this is done, we can straihgten logic around memmap intialization
in page_alloc, and I feel it will get simpler that today in the end.

> Thanks,
> Andrea

-- 
Sincerely yours,
Mike.