linux-kernel - Re: [PATCH V5 1/4] ACPI: Support Generic Initiator only domains

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: <CAPcyv4jrXvPOvoBCW8H42_og1wJ_t9_=5N4C7-OugYyNzdqBLA@mail.gmail.com>
Date:   Sat, 16 Nov 2019 12:45:23 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jonathan Cameron <jonathan.cameron@...wei.com>
Cc:     Tao Xu <tao3.xu@...el.com>, Linux MM <linux-mm@...ck.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        X86 ML <x86@...nel.org>, Keith Busch <keith.busch@...el.com>,
        Jérôme Glisse <jglisse@...hat.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Linuxarm <linuxarm@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH V5 1/4] ACPI: Support Generic Initiator only domains

On Thu, Nov 14, 2019 at 3:27 AM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:
[..]
> Hi Dan,
>
> Agreed that it makes sense to expand how we describe these cases a bit.
> To make sure I've understood correctly let me paraphrase what you
> are proposing (and tweak it a bit ;)
>
> Assuming for this purpose we don't put GIs in CPU nodes as that makes
> for really fiddly explanation. In reality the code will need to handle
> that.
>
> 1) Leave access0 as it currently is with this series - so continue to
>    not distinguish between CPU nodes and Generic Initator containing ones?

Yes, but with the caveat that I think 2) also needs to be part of the
series before it goes upstream. I.e. don't regress the amount of
default information just because a generic initiator is present.

> 2) Add access 1 which is effectively access0 ignoring Generic Initiators?

Effectively yes, but I'd say it differently. Always display the access
class for the local initiator as defined by the HMAT as access0, but
also include the "local" cpu node.

> My feeling is that any existing users of access0 are definitely not going
> to be expecting generic initiators, so we might want to do this the other
> way around. access0 is only CPUs and memory, access1 is including
> generic initiators.  If there are no GIs don't expose access1 at all?

There are no consumers of the information that I know of, so I do not
see the risk of regression.

> For now we could simply block the GI visibility in access0 and deal
> with access1 as a separate series.  I suspect we will get push back
> as there are no known users of our new access1 so it may take a while
> to prove utility and get it accepted.

The problem is that HMAT gives an unequivocal answer for "local"
because it lists it in the table explicitly. Everything else is a
subjective determination from parsing the performance data and picking
a metric. If access0 is a GI, then let sysfs just reflect that truth.