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]
Date:   Mon, 23 Aug 2021 13:17:03 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] irqchip/gic: Convert to handle_strict_flow_irq()

On Mon, 23 Aug 2021 11:38:58 +0100,
Valentin Schneider <valentin.schneider@....com> wrote:
> 
> On 23/08/21 10:33, Marc Zyngier wrote:
> > On Sun, 22 Aug 2021 23:16:10 +0100,
> > Valentin Schneider <valentin.schneider@....com> wrote:
> >>
> >> On 18/08/21 17:58, Marc Zyngier wrote:
> >> > There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
> >> > the irqchip flow to use either handle_fasteoi_ack_irq or
> >> > handle_fasteoi_mask_irq, which won't play very nicely with this.
> >> > Someone said Cavium?
> >> >
> >>
> >> Humph...
> >>
> >> I'm not familiar at all with the gpiolib irqchips, but I was under the
> >> impression those would involve chained IRQs (it does appear to be the case
> >> for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled
> >> via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever
> >> flow was installed by the relevant driver.
> >
> > Not all of them are built like this. There is actually a bunch of
> > these build as full hierarchies (QC, nvidia and some others).
> >
> 
> I see, thanks!
> 
> >> I can't easily grok what goes on between that gpio-thunderx.c driver and
> >> gpiolib, but since that GPIO chip has
> >>
> >>         .irq_eoi		= irq_chip_eoi_parent,
> >>
> >> and
> >>
> >>         girq->parent_domain =
> >>                 irq_get_irq_data(txgpio->msix_entries[0].vector)->domain;
> >>
> >> (GPIOs hooked to MSI-X? Do I want to know?)
> >
> > It's good, isn't it? TX1 has all its HW appearing as PCI, even if it
> > clearly isn't PCI underneath.
> >
> >>
> >> I'm guessing it is *not* chained, which means the irq_set_handler_locked()
> >> affects the entire stack :/
> >
> > It does. We can probably fix that, but I won't be able to test (my TX1
> > was taken away a few months ago...). I'll accept body donations, for
> > scientific purposes.
> >
> 
> Looks like there are still some over on s/packet/equinix/, so I should be
> able to poke at one.

That's where mine used to live, but the WoA people decided that I
really didn't need one, and I'm now only allowed to borrow one of the
old eMAGs. If you can pull strings, let me know! :D

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ