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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <18899.13455.965983.674389@cargo.ozlabs.ibm.com>
Date:	Wed, 1 Apr 2009 20:31:59 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf_counter: allow and require one-page mmap on
 counting counters

Peter Zijlstra writes:

> >   There will still be some issues on powerpc because of our
> > lazy interrupt disabling scheme, so some work might have to get
> > deferred until we soft-enable interrupts, but we have a way to manage
> > that.
> 
> Hmm, you're saying ppc always uses NMIs, even when !hw_event.nmi?

The PMU interrupts are always handled the same way at the moment,
which is to say they're handled when they come in whether or not
interrupts are soft-enabled.  The way things work is that
local_irq_disable etc. only soft-disable interrupts (clear a per-cpu
interrupts enabled flag in memory).  Interrupts don't get
hard-disabled (i.e. we don't clear the CPU's hardware interrupt enable
flag) until we actually get an interrupt.  A PMU interrupt can't be
taken while interrupts are hard-disabled but it can be taken while
interrupts are soft-disabled, so from that point of view it's an NMI.

The way that interrupts get hard-disabled is that the interrupt entry
code for regular interrupts and timer interrupts (but not PMU
interrupts) first checks the soft-enable flag.  If that flag is clear,
i.e. interrupts are soft-disabled, it clears the copy of the CPU
interrupt enable in the saved state from the interrupt and returns,
meaning that the code that was interrupted gets resumed with its
hardware interrupt enable bit clear.  That works because the CPU
doesn't automatically ack the interrupt with the interrupt controller
when it takes the interrupt, so the interrupt request will persist and
the CPU will take the interrupt again once the hardware interrupt
enable bit is set.

So in the period between soft-disabling and hard-disabling interrupts
it's possible to get a PMU interrupt.  If there are things we want to
do that we can't if interrupts were soft-disabled, we will have to
defer them to the point where interrupts get soft-enabled again.

> BTW, how's progress with the lazy switching?

Umm, I've been focussing more on things that affect the ABI at this
stage, I'm afraid, plus I was waiting for the dust to settle a bit on
the changes you're making.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ