linux-kernel - Re: [PATCH 1/2] perf/x86/intel: enable CPU ref

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:   Tue, 30 May 2017 18:55:49 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Stephane Eranian <eranian@...gle.com>
cc:     Peter Zijlstra <peterz@...radead.org>,
        Vince Weaver <vincent.weaver@...ne.edu>,
        Andi Kleen <ak@...ux.intel.com>,
        "Liang, Kan" <kan.liang@...el.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "acme@...hat.com" <acme@...hat.com>,
        "jolsa@...hat.com" <jolsa@...hat.com>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP
 counter

On Tue, 30 May 2017, Stephane Eranian wrote:

> On Tue, May 30, 2017 at 2:25 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Sun, May 28, 2017 at 01:31:09PM -0700, Stephane Eranian wrote:
> >> Ultimately, I would like to see the watchdog move out of the PMU. That
> >> is the only sensible solution.
> >> You just need a resource able to interrupt on NMI or you handle
> >> interrupt masking in software as has
> >> been proposed on LKML.
> >
> > So even if we do the soft masking, we still need to deal with regions
> > where the interrupts are disabled. Once an interrupt hits the soft mask
> > we still hardware mask.
> >
> What I was thinking is that you never hardware mask, software always
> catches the hw interrupts and keeps them pending or deliver them
> depending on sw mask.

That does not work.

  1) You still need some sections where you must have hardware masking.

  2) Software cannot keep them pending in hardware other than disabling
     interrupts at the CPU level and returning to the interrupted sections
     without issuing EOI. Reenabling them at the CPU level will reinject
     them in hardware.

     If we actually want send the EOI and keep a irq pending mask in
     software then we cannot do that quick in the low level entry code. We
     need to go up into the generic interrupt code, take a bunch of locks
     which expect interrupts disable and figure out what to do with the
     interrupt.

     That's required because the low level entry code has no idea how to
     deal with that interrupt, i.e. which physical interrupt controller to
     talk to. Due to our stacked irq chips we can end up with rather
     complex call chains there.

     Of course this involves locking which will deadlock if such a lock has
     been taken at some other place with interrupts just soft disabled.

Thanks,

	tglx