linux-kernel - Re: [PATCH] arch: powerpc: pci-common: fix wrong return value check on phd

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: <87in6dvv89.fsf@concordia.ellerman.id.au>
Date:   Thu, 21 Jun 2018 10:28:22 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Daniel Walker <danielwa@...co.com>,
        "Guilherme G. Piccoli" <guilherme@...ccoli.net>,
        benh@...nel.crashing.org
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        xe-kernel@...ernal.cisco.com, linux-kernel@...r.kernel.org,
        Paul Mackerras <paulus@...ba.org>,
        linuxppc-dev@...ts.ozlabs.org,
        Mauro Rodrigues <maurosr@...ux.vnet.ibm.com>,
        linux-pci@...r.kernel.org
Subject: Re: [PATCH] arch: powerpc: pci-common: fix wrong return value check on phd_id

Hi Daniel,

Sorry we broke things for you.

Daniel Walker <danielwa@...co.com> writes:
> On 06/19/2018 09:26 AM, Guilherme G. Piccoli wrote:
>>> [...]
>>> What your doing is changing the phb_id to some transformation of "reg" for
>>> all platforms except which have "ibm,opal-phbid". This is what we observe.
>>> This is a radical altering of the prior phb_id selection before your patch.
...
>
> I didn't look into changing the behavior on our side because it didn't 
> look like the intent of the patch was to make a global change. I can 
> take a look at changing this behavior on our side , given that this was 
> intended by your changes.

You're right the change log and the patch are a bit out of sync, that
was probably my fault.

> However, they're may be other platforms or drivers which depend on these 
> numbers getting set a certain way, so there may be other userspace 
> dependencies on these values.

That's true, though I think yours is the first report we've had of
problems.

The old behaviour relied on device tree ordering in nearly all cases, so
you basically get whatever order your firmware happened to flatten the
device tree in.

That tends to be consistent on a single system or with a single firmware
version, but it's not stable in general. If your firmware changes, or
you kexec then the ordering can change.

So I'd definitely prefer we didn't go back to that behaviour, because
it's basically "random order".

If there's anything you can do on your end to cope with the new ordering
that would be great.

cheers