linux-kernel - Re: [PATCH] irqchip: plic: Fix priority base offset

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: <CAKmqyKPsoi7F_NNLKcm269=VAgdvsUV7HdF3dtkpMBzaKbHhtA@mail.gmail.com>
Date:   Wed, 20 Mar 2019 17:04:58 -0700
From:   Alistair Francis <alistair23@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Alistair Francis <Alistair.Francis@....com>,
        "palmer@...ive.com" <palmer@...ive.com>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] irqchip: plic: Fix priority base offset

On Wed, Mar 20, 2019 at 4:49 PM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Wed, Mar 20, 2019 at 10:39:52PM +0000, Alistair Francis wrote:
> > According to the FU540 and E31 manuals the PLIC source priority
> > address starts at an offset of 0x04 and not 0x00. To aviod confusion
> > update the address and source offset to match the documentation. This
> > causes no difference in functionality.
>
> Well, it starts at 0x00, but the first one is reserved.  If you think
> that is too confusing I'd rather throw in a comment explaining this
> fact rather than making the calculating more complicated.

It doesn't mention that it starts at 0 when you look here:
https://sifive.cdn.prismic.io/sifive%2F834354f0-08e6-423c-bf1f-0cb58ef14061_fu540-c000-v1.0.pdf
(pg. 61).

I agree that it's the same as starting as 0 and reserving the first
one, but this means that the macros are actually at the wrong address
and we need to remember not to use 0. This ends up forgotten and I
have seen bugs in OpenSBI and QEMU as they have a similar
implementation. It's possible some future code update will forget this
as well.

I think it's much clearer to define the correct values and just
subtract 1, the calculation really isn't more complicated.

Alistair