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
| ||
|
Date: Thu, 24 Feb 2022 19:06:12 +0000 From: Marc Zyngier <maz@...nel.org> To: Hector Martin <marcan@...can.st>, Mark Rutland <mark.rutland@....com> Cc: Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh+dt@...nel.org>, Sven Peter <sven@...npeter.dev>, Alyssa Rosenzweig <alyssa@...enzweig.io>, Mark Kettenis <mark.kettenis@...all.nl>, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org Subject: Re: [PATCH v2 0/7] irqchip/apple-aic: Add support for AICv2 On Thu, 24 Feb 2022 18:26:41 +0000, Mark Rutland <mark.rutland@....com> wrote: > > On Thu, Feb 24, 2022 at 10:07:34PM +0900, Hector Martin wrote: > > Hi folks, > > Hi Hector, > > > In the t6000/t6001 (M1 Pro / Max) SoCs, Apple introduced a new version > > of their interrupt controller. This is a significant departure from > > AICv1 and seems designed to better scale to larger chips. This series > > adds support for it to the existing AIC driver. > > > > Gone are CPU affinities; instead there seems to be some kind of > > "automagic" dispatch to willing CPU cores, and cores can also opt-out > > via an IMP-DEF sysreg (!). Right now the bootloader just sets up all > > cores to accept IRQs, and we ignore all this and let the magic > > algorithm pick a CPU to accept the IRQ. > > Maybe that's ok for the set of peripherals attached, but in general that > violates existing expectations regarding affinity, and I fear there'll > be some subtle brokenness resulting from this automatic target > selection. > > For example, in the perf events subsystem there are PMU drivers (even > those for "uncore" or "system" devices which are shared by many/all > CPUs) which rely on a combination of interrupt affinity and local IRQ > masking (without any other locking) to provide exclusion between a PMU's > IRQ handler and any other management operations for that PMU (which are > all handled from the same CPU). It will definitely break anything that relies on managed interrupts, where the kernel expects to allocate interrupts that have a strict affinity. Drivers using this feature can legitimately expect that they can keep their state in per-CPU pointers, and that obviously breaks. This may affect any PCIe device with more than a couple of queues. Maybe users of this HW do not care (yet), but we'll have to find a way to tell drivers of the limitation. M. -- Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists