| 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
| ||
|
Message-ID: <86ed9lnbb5.wl-maz@kernel.org>
Date: Tue, 28 May 2024 17:36:14 +0100
From: Marc Zyngier <maz@...nel.org>
To: Anup Patel <apatel@...tanamicro.com>
Cc: Rob Herring <robh@...nel.org>,
Saravana Kannan <saravanak@...gle.com>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Atish Patra <atishp@...shpatra.org>,
Andrew Jones <ajones@...tanamicro.com>,
Sunil V L <sunilvl@...tanamicro.com>,
Anup Patel <anup@...infault.org>,
linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v4] of: property: Add fw_devlink support for interrupt-map property
On Thu, 09 May 2024 13:08:20 +0100,
Anup Patel <apatel@...tanamicro.com> wrote:
>
> Some of the PCI host controllers (such as generic PCI host controller)
> use "interrupt-map" DT property to describe the mapping between PCI
> endpoints and PCI interrupt pins. This is the only case where the
> interrupts are not described in DT.
>
> Currently, there is no fw_devlink created based on "interrupt-map"
> DT property so interrupt controller is not guaranteed to be probed
> before the PCI host controller. This affects every platform where
> both PCI host controller and interrupt controllers are probed as
> regular platform devices.
>
> This creates fw_devlink between consumers (PCI host controller) and
> supplier (interrupt controller) based on "interrupt-map" DT property.
>
> Signed-off-by: Anup Patel <apatel@...tanamicro.com>
> Reviewed-by: Saravana Kannan <saravanak@...gle.com>
> ---
> Changes since v3:
> - Added a comment about of_irq_parse_raw()
> - Removed redundant NULL assignments to sup_args.np
> Changes since v2:
> - No need for a loop to find #interrupt-cells property value
> - Fix node de-reference leak when index is greater than number
> of entries in interrupt-map property
> Changes since v1:
> - Updated commit description based on Rob's suggestion
> - Use of_irq_parse_raw() for parsing interrupt-map DT property
This patch breaks badly on my M1 Mini, with a continuous stream of
boot time warnings lasting about 100 seconds:
[ 97.832335] ------------[ cut here ]------------
[ 97.836955] /soc/pcie@...000000/pci@2,0 interrupt-map failed, using interrupt-controller
[ 97.845072] WARNING: CPU: 0 PID: 1 at drivers/of/irq.c:277 of_irq_parse_raw+0x620/0x730
[ 97.853087] Modules linked in:
[ 97.856139] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.10.0-rc1 #2915
[ 97.864163] Hardware name: Apple Mac mini (M1, 2020) (DT)
[ 97.869570] pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 97.876546] pc : of_irq_parse_raw+0x620/0x730
[ 97.880907] lr : of_irq_parse_raw+0x620/0x730
[ 97.885267] sp : ffffc000800538a0
[ 97.888581] x29: ffffc000800538a0 x28: 0000000000000000 x27: ffffffffff5ffc68
[ 97.895732] x26: ffffc000800539a4 x25: ffffffffff5ffbbc x24: ffffc00080053a48
[ 97.902883] x23: ffffe3ff73284e68 x22: ffffb7889aede6d0 x21: ffffe3ff735f9320
[ 97.910034] x20: ffffc00080053964 x19: ffffb7889aede6d0 x18: ffffffffffffffff
[ 97.917185] x17: 7075727265746e69 x16: 20676e697375202c x15: 64656c6961662070
[ 97.924336] x14: 616d2d7470757272 x13: 72656c6c6f72746e x12: 6f632d7470757272
[ 97.931487] x11: 65746e6920676e69 x10: ffffe3ff740bcb68 x9 : ffffe3ff72335b38
[ 97.938639] x8 : 00000001000028a4 x7 : ffffe3ff740afc08 x6 : 00000000000038a4
[ 97.945789] x5 : 00000000000067b0 x4 : c0000001000028a4 x3 : 0000000000000000
[ 97.952940] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffb784c16ade00
[ 97.960092] Call trace:
[ 97.962534] of_irq_parse_raw+0x620/0x730
[ 97.966545] parse_interrupt_map+0xfc/0x188
[ 97.970731] of_fwnode_add_links+0x170/0x1e0
[ 97.975004] fw_devlink_parse_fwtree+0x44/0x98
[ 97.979452] fw_devlink_parse_fwtree+0x6c/0x98
[ 97.983899] fw_devlink_parse_fwtree+0x6c/0x98
[ 97.988347] device_add+0x610/0x6a8
[ 97.991836] of_device_add+0x4c/0x70
[ 97.995411] of_platform_device_create_pdata+0xa0/0x160
[ 98.000644] of_platform_bus_create+0x184/0x370
[ 98.005178] of_platform_populate+0x68/0x160
[ 98.009451] of_platform_default_populate_init+0xf4/0x118
[ 98.014859] do_one_initcall+0x4c/0x320
[ 98.018695] do_initcalls+0xf4/0x1d8
[ 98.022271] kernel_init_freeable+0x12c/0x280
[ 98.026632] kernel_init+0x2c/0x1f8
[ 98.030120] ret_from_fork+0x10/0x20
[ 98.033696] ---[ end trace 0000000000000000 ]---
which comes from 10a20b34d735f ("of/irq: Don't ignore
interrupt-controller when interrupt-map failed").
Each of the 3 PCIe ports are described as such:
port02: pci@2,0 {
device_type = "pci";
reg = <0x1000 0x0 0x0 0x0 0x0>;
reset-gpios = <&pinctrl_ap 33 GPIO_ACTIVE_LOW>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &port02 0 0 0 0>,
<0 0 0 2 &port02 0 0 0 1>,
<0 0 0 3 &port02 0 0 0 2>,
<0 0 0 4 &port02 0 0 0 3>;
status = "disabled";
};
and get probed *972 times*, which seem... excessive, given that there
are only 4 entries per port.
> ---
> drivers/of/property.c | 52 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index a6358ee99b74..2d749a18b037 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1311,6 +1311,57 @@ static struct device_node *parse_interrupts(struct device_node *np,
> return of_irq_parse_one(np, index, &sup_args) ? NULL : sup_args.np;
> }
>
> +static struct device_node *parse_interrupt_map(struct device_node *np,
> + const char *prop_name, int index)
> +{
> + const __be32 *imap, *imap_end, *addr;
> + struct of_phandle_args sup_args;
> + u32 addrcells, intcells;
> + int i, imaplen;
> +
> + if (!IS_ENABLED(CONFIG_OF_IRQ))
> + return NULL;
> +
> + if (strcmp(prop_name, "interrupt-map"))
> + return NULL;
> +
> + if (of_property_read_u32(np, "#interrupt-cells", &intcells))
> + return NULL;
> + addrcells = of_bus_n_addr_cells(np);
> +
> + imap = of_get_property(np, "interrupt-map", &imaplen);
> + if (!imap || imaplen <= (addrcells + intcells))
This is "interesting". You compare a number of *bytes* with a number
of cells. Only off by a factor of 4...
Also, you need a minimum of one extra cell to hold the phandle, and a
yet unknown number of cells for whatever follows the phandle.
> + return NULL;
> + imap_end = imap + imaplen;
Same problem, with pointer arithmetic this time.
> +
> + while (imap < imap_end) {
> + addr = imap;
> + imap += addrcells;
> +
> + sup_args.np = np;
> + sup_args.args_count = intcells;
> + for (i = 0; i < intcells; i++)
> + sup_args.args[i] = be32_to_cpu(imap[i]);
> + imap += intcells;
> +
> + /*
> + * Upon success, the function of_irq_parse_raw() returns
> + * interrupt controller DT node pointer in sup_args.np.
> + */
> + if (of_irq_parse_raw(addr, &sup_args))
> + return NULL;
> +
> + if (!index)
> + return sup_args.np;
> +
> + of_node_put(sup_args.np);
> + imap += sup_args.args_count + 1;
This really doesn't map (pun intended) to the way the interrupt-map
entries are built. You need to account for the parent address size as
well.
I'll post a patch fixing both issues.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists