linux-kernel - Re: [PATCH -tip] x86: do_IRQ - send EOI for x86-32 on irq without handler v2

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:	Wed, 8 Apr 2009 17:55:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [PATCH -tip] x86: do_IRQ - send EOI for x86-32 on irq without
	handler v2


* Cyrill Gorcunov <gorcunov@...il.com> wrote:

> [Ingo Molnar - Wed, Apr 08, 2009 at 04:52:18PM +0200]
> | 
> | * Cyrill Gorcunov <gorcunov@...nvz.org> wrote:
> | 
> | > Ingo, I think introducing additional dummy here would be a bit 
> | > expencive -- a number of callers of ack_APIC_irq just should not 
> | > check for disable_apic since it's not needed. disable_apic is to 
> | > depend on CONFIG_X86_LOCAL_APIC rather then CONFIG_X86_64 
> | > actually. So make it then. Or you mean something else? Like new 
> | > apic->write_eoi operation? (I'm a bit tired so brain is a half 
> | > functional now :)
> | 
> | no, i meant a dummy apic->write() method in the !apic case. Check 
> | what ack_APIC_irq() does internally.
> | 
> | 	Ingo
> |
> 
> Of course I saw how ack_APIC_irq implemented :) It's already guarded
> by CONFIG_X86_LOCAL_APIC and I could just move check for disable_apic
> right here (ie it could be like
> 
> static inline void ack_APIC_irq(void)
> {
> #ifdef CONFIG_X86_LOCAL_APIC
> 	/*
> 	 * ack_APIC_irq() actually gets compiled as a single instruction
> 	 * ... yummie.
> 	 */
> 
> 	if (!disable_apic)
> 		/* Docs say use 0 for future compatibility */
> 		apic_write(APIC_EOI, 0);
> #endif
> }
> 
> but what is bothering me is that a number of ack_APIC_irq callers
> will pass execution with always disable_apic=0 and as result
> this checking would be just spedning cycles for free.
> 
> So Ingo, it seems I miss something on what you mean. apic->write 
> is already called only for CONFIG_X86_LOCAL_APIC here as well and 
> the arguable point is where to check for disable_apic variable. 
> But do_IRQ is a special case (wrt to say smp_apic_timer_interrupt 
> or setup_local_APIC. I mean as example -- setup_local_APIC is not 
> even called for disable_apic=1).
> 
> /me: scratching the head heavily

You should look into how apic_write() is implemented. It is a call 
to apic->write().

So my suggestion is that you could implement a freely callable 
ack_APIC_irq() by replacing the apic->write() method with a NOP 
method in the apic-disabled case.

Does that sound good to you?

	Ingo
--
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/