linux-kernel - Re: Issues with OF_DYNAMIC PCI bridge node generation (kmemleak/interrupt-map IC reg property)

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: <CAL_JsqJF6s8GsGe1w6KEkeECab956YiBSFbdbHOiiCv2+v3MAA@mail.gmail.com>
Date: Tue, 12 Aug 2025 11:59:06 -0500
From: Rob Herring <robh@...nel.org>
To: Lizhi Hou <lizhi.hou@....com>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>, maz@...nel.org, devicetree@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Issues with OF_DYNAMIC PCI bridge node generation
 (kmemleak/interrupt-map IC reg property)

On Tue, Aug 12, 2025 at 10:53 AM Lizhi Hou <lizhi.hou@....com> wrote:
>
>
> On 8/12/25 00:42, Lorenzo Pieralisi wrote:
> > On Mon, Aug 11, 2025 at 08:26:11PM -0700, Lizhi Hou wrote:
> >> On 8/11/25 01:42, Lorenzo Pieralisi wrote:
> >>
> >>> Hi Lizhi, Rob,
> >>>
> >>> while debugging something unrelated I noticed two issues
> >>> (related) caused by the automatic generation of device nodes
> >>> for PCI bridges.
> >>>
> >>> GICv5 interrupt controller DT top level node [1] does not have a "reg"
> >>> property, because it represents the top level node, children (IRSes and ITSs)
> >>> are nested.
> >>>
> >>> It does provide #address-cells since it has child nodes, so it has to
> >>> have a "ranges" property as well.
> >>>
> >>> You have added code to automatically generate properties for PCI bridges
> >>> and in particular this code [2] creates an interrupt-map property for
> >>> the PCI bridges (other than the host bridge if it has got an OF node
> >>> already).
> >>>
> >>> That code fails on GICv5, because the interrupt controller node does not
> >>> have a "reg" property (and AFAIU it does not have to - as a matter of
> >>> fact, INTx mapping works on GICv5 with the interrupt-map in the
> >>> host bridge node containing zeros in the parent unit interrupt
> >>> specifier #address-cells).
> >> Does GICv5 have 'interrupt-controller' but not 'interrupt-map'? I think
> >> of_irq_parse_raw will not check its parent in this case.
> > But that's not the problem. GICv5 does not have an interrupt-map,
> > the issue here is that GICv5 _is_ the parent and does not have
> > a "reg" property. Why does the code in [2] check the reg property
> > for the parent node while building the interrupt-map property for
> > the PCI bridge ?
>
> Based on the document, if #address-cells is not zero, it needs to get
> parent unit address. Maybe there is way to get the parent unit address
> other than read 'reg'?  Or maybe zero should be used as parent unit
> address if 'reg' does not exist?
>
> Rob, Could you give us some advise on this?

If there's no 'reg', then 'ranges' parent address can be used. If
'ranges' is boolean (i.e. 1:1), then shrug. Just use 0. Probably, 0
should just always be used because I don't think it ever matters.

>From my read of the kernel's interrupt parsing code, only the original
device's node (i.e. the one with 'interrupts') address is ever used in
the parsing and matching. So the values in the parent's address cells
don't matter. If a subsequent 'interrupt-map' is the parent, then the
code would compare the original address with the parent's
interrupt-map entries (if not masked). That kind of seems wrong to me,
but also unlikely to ever occur if it hasn't already. And that code is
something I don't want to touch because we tend to break platforms
when we do. The addresses are intertwined with the interrupt
translating because interrupts used to be part of the buses (e.g ISA).
That hasn't been the case for any h/w in the last 20 years.