linux-kernel - Re: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem

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: <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz>
Date:   Mon, 4 Dec 2017 13:32:44 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Andrea Reale <ar@...ux.vnet.ibm.com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, m.bielski@...tualopensystems.com,
        arunks@....qualcomm.com, mark.rutland@....com,
        scott.branden@...adcom.com, will.deacon@....com,
        qiuxishi@...wei.com, catalin.marinas@....com, realean2@...ibm.com
Subject: Re: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially
 removed vmemmap mem

On Mon 04-12-17 11:49:09, Andrea Reale wrote:
> On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> > On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > > When hot-removing memory we need to free vmemmap memory.
> > > However, depending on the memory is being removed, it might
> > > not be always possible to free a full vmemmap page / huge-page
> > > because part of it might still be used.
> > > 
> > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > > hot-remove") introduced a workaround for x86
> > > hot-remove, by which partially unused areas are filled with
> > > the 0xFD constant. Full pages are only removed when fully
> > > filled by 0xFDs.
> > > 
> > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > > the goal of using it in place of 0xFDs. For now, this will be used for
> > > the arm64 port of memory hot remove, but the idea is to eventually use
> > > the same mechanism for x86 as well.
> > 
> > Why cannot you use the same approach as x86 have? Have a look at the
> > vmemmap_free at al.
> > 
> 
> This arm64 hot-remove version (including vmemmap_free) is indeed an
> almost 1-to-1 port of the x86 approach. 
> 
> If you look at the first version of the patchset we submitted a while 
> ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
> x86 approach of filling unsued page structs with 0xFDs. Commenting on
> that, Mark suggested (and, indeed, I agree with him) that relying on a
> magic constant for marking some portions of physical memory was quite
> ugly. That is why we have used memblock for the purpose in this revised
> patchset.
> 
> If you have a different view and any concrete suggestion on how to
> improve this, it is definitely very well welcome. 

I would really prefer if those archictectues shared the code (and
concept) as much as possible. It is really a PITA to wrap your head
around each architectures for reasons which are not inherent to that
specific architecture. If you find the way how x86 is implemented ugly,
then all right, but making arm64 special just for the matter of taste is
far from ideal IMHO.
-- 
Michal Hocko
SUSE Labs