linux-kernel - Re: [PATCH 0/8] implement "memmap on memory" feature on s390

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: <ec3fcd7d-17a0-4901-9261-a204c2c50c52@redhat.com>
Date:   Fri, 17 Nov 2023 00:08:31 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Sumanth Korikkar <sumanthk@...ux.ibm.com>,
        linux-mm <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Oscar Salvador <osalvador@...e.de>, Michal Hocko <mhocko@...e.com>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        linux-s390 <linux-s390@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/8] implement "memmap on memory" feature on s390

On 14.11.23 19:02, Sumanth Korikkar wrote:
> Hi All,
> 
> The patch series implements "memmap on memory" feature on s390 and
> provides the necessary fixes for it.

Thinking about this, one thing that makes s390x different from all the 
other architectures in this series is the altmap handling.

I'm curious, why is that even required?

A memmep that is not marked as online in the section should not be 
touched by anybody (except memory onlining code :) ). And if we do, it's 
usually a BUG because that memmap might contain garbage/be poisoned or 
completely stale, so we might want to track that down and fix it in any 
case.

So what speaks against just leaving add_memory() populate the memmap 
from the altmap? Then, also the page tables for the memmap are already 
in place when onlining memory.

Then, adding two new notifier calls on start of memory_block_online() 
called something like MEM_PREPARE_ONLINE and end the end of 
memory_block_offline() called something like MEM_FINISH_OFFLINE is still 
suboptimal, but that's where standby memory could be 
activated/deactivated, without messing with the altmap.

That way, the only s390x specific thing is that the memmap that should 
not be touched by anybody is actually inaccessible, and you'd 
activate/deactivate simply from the new notifier calls just the way we 
used to do.

It's still all worse than just adding/removing memory properly, using a 
proper interface -- where you could alloc/free an actual memmap when the 
altmap is not desired. But I know that people don't want to spend time 
just doing it cleanly from scratch.

-- 
Cheers,

David / dhildenb