linux-kernel - Re: [PATCH] perf/arm-cmn: Add shutdown routine

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] [day] [month] [year] [list]

Message-ID: <20221130132945.GA27624@willie-the-truck>
Date:   Wed, 30 Nov 2022 13:29:45 +0000
From:   Will Deacon <will@...nel.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Geoff Blake <blakgeof@...zon.com>, linux-kernel@...r.kernel.org,
        catalin.marinas@....com, kernel-team@...roid.com,
        linux-arm-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] perf/arm-cmn: Add shutdown routine

On Wed, Nov 30, 2022 at 12:28:17PM +0000, Robin Murphy wrote:
> On 2022-11-29 19:52, Will Deacon wrote:
> > On Fri, 25 Nov 2022 17:01:53 -0600, Geoff Blake wrote:
> > > The CMN driver does not gracefully handle all
> > > restart cases, such as kexec.  On a kexec if the
> > > arm-cmn driver is in use it can be left in a state
> > > with still active  events that can cause spurious and/or
> > > unhandled interrupts that appear as non-fatal kernel errors
> > > like below, that can be confusing and misleading:
> > > 
> > > [...]
> > 
> > Applied to will (for-next/perf), thanks!
> > 
> > [1/1] perf/arm-cmn: Add shutdown routine
> >        https://git.kernel.org/will/c/316f862a787c
> 
> Oh, if I'd seen this I'd have said the same thing as when asked about it
> off-list, that it's needlessly overcomplicated and doesn't really solve the
> problem anyway. If there's a need to be robust against spurious interrupts
> then that needs to be done in the interrupt handler.
> 
> Even if we do think it's worth stopping the PMU on shutdown, as we do on
> remove, that still only needs a single register write (per the current
> remove implementation).

Sorry Robin, I didn't spot that you weren't on cc for this. I've dropped the
patch locally and I'll update the branches later on today.

Please can you help Geoff come up with something better?

Will