linux-kernel - Re: percpu irq APIs and perf

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: <C2D7FE5348E1B147BCA15975FBA23075F44D5D39@IN01WEMBXA.internal.synopsys.com>
Date:	Mon, 14 Dec 2015 05:50:39 +0000
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	Marc Zyngier <marc.zyngier@....com>
CC:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Jason Cooper <jason@...edaemon.net>,
	Peter Zijlstra <peterz@...radead.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	arcml <linux-snps-arc@...ts.infradead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"maxime.ripard@...e-electrons.com" <maxime.ripard@...e-electrons.com>
Subject: Re: percpu irq APIs and perf

On Friday 11 December 2015 11:28 PM, Marc Zyngier wrote:
>>> But auto-enabling cannot be done from a single CPU. It can only be done
>>> >> from the core that is going to be delivered that interrupt. This
>>> >> requires access to registers that are simply not available to other CPUs.
>> > 
>> > I'm not talking about eliminating enable_percpu_irq() call from all cores and
>> > still getting the auto-enable semantics. What I mean is doing the equivalent of
>> > 
>> >      irq_set_status_flags(irq, IRQ_NOAUTOEN);
>> > 
>> > from within request_percpu_irq_xxx() based on an additional arg (vs. doing it
>> > aprioiri outside).
>> > 
>> > OTOH, thinking a bit more abt this, I think the current semantics of auto-disable
>> > w/o any arg is just fine. Most percpu irqs in general purpose drivers would want
>> > the auto-disable anyways. Only for core irws such as timer / IPI etc do we want
>> > auto-enable.
> So assuming we can do this (forgetting about any form of HW limitation):
> CPU0 request the per-CPU IRQ with an AUTOEN flag. What happens on CPU1?
> Are you expecting it to immediately be able to take interrupts? What
> handler data gets passed to it?

Right - autoen=true will only help on CPU0. Others will still need to call enable
- for register tinkling etc. A true autoen API should have done that across the
board which it clearly can't and hence is pointless.

Thx,
-Vineet
--
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/