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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 15 Dec 2020 11:14:50 +0000 From: Valentin Schneider <valentin.schneider@....com> To: Marc Zyngier <maz@...nel.org> Cc: Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Andrew Lunn <andrew@...n.ch>, Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>, Jason Cooper <jason@...edaemon.net>, Scott Branden <sbranden@...adcom.com>, Gregory Clement <gregory.clement@...tlin.com>, Florian Fainelli <f.fainelli@...il.com>, Ray Jui <rjui@...adcom.com>, Thomas Gleixner <tglx@...utronix.de>, Sebastian Hesselbarth <sebastian.hesselbarth@...il.com> Subject: Re: [PATCH 3/5] irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq() On 15/12/20 10:19, Marc Zyngier wrote: > Hi Gunter, > > On 2020-12-15 00:21, Guenter Roeck wrote: >> On Mon, Nov 09, 2020 at 09:41:19AM +0000, Valentin Schneider wrote: >>> As done for the Arm GIC irqchips, move IPIs to >>> handle_percpu_devid_irq() as >>> handle_percpu_devid_fasteoi_ipi() isn't actually required. >>> >>> Signed-off-by: Valentin Schneider <valentin.schneider@....com> >> >> This patch results in boot failures (silent stall) for the qemu >> raspi2 emulation. Unfortunately it can not be reverted because >> handle_percpu_devid_fasteoi_ipi no longer exists in next-20201214, >> so I don't know if it is the only problem. > > This is odd. This works just fine for me on both the RPi2 and 3 > emulation, running a full Debian userspace. Could this be caused > by the version of QEMU you are using? Here's what I have: > > $ qemu-system-arm --version > QEMU emulator version 5.1.0 (Debian 1:5.1+dfsg-4+b1) > > Could you try the following hack and let me know if that helps? > Thanks for looking into this. It does look like I inverted the ordering of that mailbox write vs the handling of the IPI. I don't see how the IPI could mess with the mailbox (unless some creative use of irq_work / smp_call), but in any case having the write in irq_ack() as you've done below should restore said ordering. > Thanks, > > M. > > diff --git a/drivers/irqchip/irq-bcm2836.c > b/drivers/irqchip/irq-bcm2836.c > index 5f5eb8877c41..25c9a9c06e41 100644 > --- a/drivers/irqchip/irq-bcm2836.c > +++ b/drivers/irqchip/irq-bcm2836.c > @@ -167,7 +167,7 @@ static void bcm2836_arm_irqchip_handle_ipi(struct > irq_desc *desc) > chained_irq_exit(chip, desc); > } > > -static void bcm2836_arm_irqchip_ipi_eoi(struct irq_data *d) > +static void bcm2836_arm_irqchip_ipi_ack(struct irq_data *d) > { > int cpu = smp_processor_id(); > > @@ -195,7 +195,7 @@ static struct irq_chip bcm2836_arm_irqchip_ipi = { > .name = "IPI", > .irq_mask = bcm2836_arm_irqchip_dummy_op, > .irq_unmask = bcm2836_arm_irqchip_dummy_op, > - .irq_eoi = bcm2836_arm_irqchip_ipi_eoi, > + .irq_ack = bcm2836_arm_irqchip_ipi_ack, > .ipi_send_mask = bcm2836_arm_irqchip_ipi_send_mask, > };
Powered by blists - more mailing lists