linux-kernel - Re: [PATCH v4] powerpc/pseries: read the lpar name from the firmware

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: <8735m1ixd6.fsf@li-e15d104c-2135-11b2-a85c-d7ef17e56be6.ibm.com>
Date:   Wed, 05 Jan 2022 17:19:49 -0600
From:   Nathan Lynch <nathanl@...ux.ibm.com>
To:     Laurent Dufour <ldufour@...ux.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v4] powerpc/pseries: read the lpar name from the firmware

Laurent Dufour <ldufour@...ux.ibm.com> writes:
> On 07/12/2021, 18:11:09, Laurent Dufour wrote:
>> The LPAR name may be changed after the LPAR has been started in the HMC.
>> In that case lparstat command is not reporting the updated value because it
>> reads it from the device tree which is read at boot time.
>> 
>> However this value could be read from RTAS.
>> 
>> Adding this value in the /proc/powerpc/lparcfg output allows to read the
>> updated value.
>
> Do you consider taking that patch soon?

This version prints an error on non-PowerVM guests the first time
lparcfg is read.

And I still contend that having this function fall back to reporting the
partition name in the DT would provide a beneficial consistency in the
user-facing API, allowing programs to avoid hypervisor-specific branches
in their code. I don't understand the resistance I've encountered here.
The fallback I'm suggesting (a root node property lookup) is certainly
not more complex than the RTAS call sequence you've already implemented.