linux-kernel - Re: [PATCH 12/21] EDAC, ghes: Add support for legacy API counters

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:   Wed, 26 Jun 2019 10:33:28 +0100
From:   James Morse <james.morse@....com>
To:     Robert Richter <rrichter@...vell.com>
Cc:     Borislav Petkov <bp@...en8.de>, Tony Luck <tony.luck@...el.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/21] EDAC, ghes: Add support for legacy API counters

Hi Robert,

On 20/06/2019 07:55, Robert Richter wrote:
> On 19.06.19 18:22:32, James Morse wrote:
>>> In any case, this patch cleans up code as old API's counter code is
>>> isolated and moved to common code. Making the counter's work for ghes
>>> is actually a side-effect here. The cleanup is a prerequisit for
>>> follow on patches.
>>
>> I'm all for removing/warning-its-broken it when ghes_edac is in use. But the convincing
>> argument is debian ships a 'current' version of edac-utils that predates 199747106934,
>> (that made all this fake csrow stuff deprecated), and debian's popcon says ~1000 people
>> have it installed.
> 
> All arm64 distribution kernels that I have checked come with:
> 
> CONFIG_EDAC_SUPPORT=y
> CONFIG_EDAC=y
> CONFIG_EDAC_LEGACY_SYSFS=y
> # CONFIG_EDAC_DEBUG is not set
> CONFIG_EDAC_GHES=y
> CONFIG_EDAC_LAYERSCAPE=m
> CONFIG_EDAC_THUNDERX=m
> CONFIG_EDAC_XGENE=m

(distros also enable drivers for hardware no-one has!)

Who uses this? edac-utils, on both arm64 and x86.

>> If you want it fixed, please don't do it as a side effect of cleanup. Fixes need to be a
>> small separate series that can be backported. (unless we're confident no-one uses it, in
>> which case, why fix it?)

> It is not that I am keen on fixing legacy edac sysfs. It just happens
> while unifying the error handlers in ghes_edac and edac_mc. As I see
> you are reluctant on just letting it go, let's just disable
> EDAC_LEGACY_SYSFS for ARM64.

That would break other drivers where those legacy counters expose valid values.

You're painting me as some kind of stubborn villan here. You're right my initial reaction
was 'what for?'. Adding new support for legacy counters that have never worked with
ghes_edac looks like the wrong thing to do.

But unfortunately edac-utils is still using this legacy interface.

If we're going to fix it, could we fix it properly? (separate series that can be
backported to stable).

> Though, I don't agree with it as there
> still could be some userland tools that use this interface that cannot
> be used any longer after a transition from x86 to arm64.

I don't think this is the right thing to do. ghes_edac's behaviour should not change
between architectures.

Where we aren't agreeing is how we fix bugs:

Its either broken, and no-one cares, we should remove it.
Or, we should fix it and those fixes should go to stable.

We can't mix fixes and features in a patch series, as the fixes then can't easily be
backported. If its ever in doubt, the patches should still be as separate fixes so the
maintainer can decide.

Thanks,

James