linux-kernel - Re: [PATCH] arm64: acpi: reenumerate topology ids

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:   Fri, 29 Jun 2018 18:23:15 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Andrew Jones <drjones@...hat.com>
Cc:     Jeremy Linton <jeremy.linton@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        ard.biesheuvel@...aro.org, shunyong.yang@...-semitech.com,
        yu.zheng@...-semitech.com, catalin.marinas@....com,
        will.deacon@....com, Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH] arm64: acpi: reenumerate topology ids

On Fri, Jun 29, 2018 at 07:03:34PM +0200, Andrew Jones wrote:
> On Fri, Jun 29, 2018 at 11:48:15AM -0500, Jeremy Linton wrote:
[..]

> >
> > If you want a human readable socket identifier that matches something
> > stamped above the socket, that is what SMBIOS is for. Queue discussion about
> > that tables reliability for functional ids. Either way, as the spec is
> > written today (or any ECRs I've seen), your definitely not going to get both
> > nice socket1, socket2, and cpu1, cpu2 out of the same PPTT/ACPIid name-space
> > since the numerical id's conflict.
> >
>
> If we don't expect the ACPI processor ID to be something useful to users,
> then I'll revert back to lobbying for counters, as those arbitrary numbers
> can't be less useful than arbitrary offsets and ACPI IDs, and, IMO, are
> more likely to make users/user apps happy.
>

I agree that ACPI processor ID may not be useful to the users, but providing
some counter based ID which is highly dependent on the ordering the firmware
table which can change between boots is highly inconsistent and unreliable
and in some sense break user ABI. So I still NACK the counter based ID.

--
Regards,
Sudeep