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] [day] [month] [year] [list]

Date:   Wed, 26 Jun 2019 10:27:23 +0000
From:   Robert Richter <rrichter@...vell.com>
To:     James Morse <james.morse@....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

On 26.06.19 10:33:28, James Morse wrote:
> On 20/06/2019 07:55, Robert Richter wrote:

> > 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.

I am sorry for mis-understanding you here. I haven't seen your
motivation for this which is now clear to me.

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

I see your point here. This is also the reason why I (try to) put
fixes at the beginning of a series to allow backports to stable (or
distros). Clearly, this must be better separated here.

> > 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.

I will better separate fix here and update in the next v3.

Thanks and sorry again,

-Robert