linux-kernel - Re: [PATCH 1/2] perf/arm-cmn: Cope with spurious IRQs better

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: <f41af5cb-7fc7-4bd3-ec9e-53071b9a41f9@amazon.com>
Date:   Wed, 30 Nov 2022 10:02:58 -0600
From:   Geoff Blake <blakgeof@...zon.com>
To:     Robin Murphy <robin.murphy@....com>
CC:     <will@...nel.org>, <mark.rutland@....com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] perf/arm-cmn: Cope with spurious IRQs better

Robin,

>From my perspective, this is a worse solution as now we're sweeping an 
issue under the rug and consuming CPU cycles handling IRQs we should not 
be getting in the first place.  While an overflow IRQ from the cmn should 
not be high frequency, there is a non-zero chance in the future it could 
be and this could lead to a very hard to debug performance issue instead 
of the current problem, which is discovering we need to clean up better 
from a noisy kernel message.

The driver as best I can grok currently is optimized to limit the amount 
of register writes for the common use-case, which is setting and unsetting 
events, so all the wiring for the PMU to feed events to the DTC is done up 
front on load: DTC_CTL's DT_EN bit is set immediately during probe, as is 
OVFL_INTR_EN. All the DN states and DTM PMU_CONFIG_PMU_EN is deferred 
for when an event is actually set, and here we go through all of them 
anyways for each event unless its bynodeid, so the expense of setting 
events grows linearly with the mesh size anyways.  

Doing a one time scan on remove/shutdown to reset everything to a 
clean state seems like a wash performance wise and wanting to keep just a 
single register write doesn't make much sense to me.  

Should I instead pull this step out as a 
generic initialization step that can live as a single chunk of code to 
make it better for maintainability?  Would that be a better solution?

- Geoff