linux-kernel - Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys

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]

Date:   Thu, 10 Sep 2020 22:31:09 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     David Hildenbrand <david@...hat.com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Michal Hocko <mhocko@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jan Höppner <hoeppner@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        linux-api@...r.kernel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys_device ?

> Am 10.09.2020 um 22:01 schrieb Dave Hansen <dave.hansen@...el.com>:
> 
> On 9/10/20 3:20 AM, David Hildenbrand wrote:
>> I was just exploring how /sys/devices/system/memory/memoryX/phys_device
>> is/was used. It's one of these interfaces that most probably never
>> should have been added but now we are stuck with it.
> 
> While I'm all for cleanups, what specific problems is phys_device causing?
> 

Mostly stumbling over it, understanding that it is basically unused with new userspace for good reason, questioning its existence.

E.g., I am working on virtio-mem support for s390x. Displaying misleading/wrong phys_device indications isn‘t particularly helpful - especially once there are different ways to hotplug memory for an architecture.

> Are you hoping that we can just remove users of memoryX/* until there
> are no more left, and this is the easiest place to start?

At least reducing it to a minimum with clear semantics. Even with automatic onlining there are still reasons why we need to keep the interface for now (e.g., reloading kexec to update the kdump headers on memory hot(un)plug). But also standby memory handling on s399x requires it (->manual onlining).