linux-kernel - Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL

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:	Sun, 13 Mar 2016 16:20:52 +0800
From:	Jianyu Zhan <nasa4836@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	mingo@...hat.com, "H. Peter Anvin" <hpa@...or.com>,
	Aravind.Gopalakrishnan@....com, brgerst@...il.com, bp@...e.de,
	feng.wu@...el.com, jiang.liu@...ux.intel.com,
	Tejun Heo <tj@...nel.org>, dvlasenk@...hat.com,
	penberg@...helsinki.fi, Yinghai Lu <yhlu.kernel@...il.com>,
	andi@...stfloor.org, Andy Lutomirski <luto@...nel.org>,
	ajm@....com, Yinghai Lu <yinghai@...nel.org>,
	Akinobu Mita <akinobu.mita@...il.com>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86/irq: update first_system_vector only when
 X86_LOCAL_PIC is on

On Sun, Mar 13, 2016 at 3:55 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> if LOCAL_APIC is disabled it does not use the interrupt, simply because there
> is no way to trigger it. That setup is inside #ifdef CONFIG_X86_LOCAL_APIC for
> exactly that reason.
>
> Just because IRQ_WORK has no config dependency on LOCAL APIC that does not
> mean it uses the interrupt gate unconditionally.
>

Thanks for clarification.

I think IRQ_WORK works as generic hardirq context callbacks, it should reply on
self IPI,  which is a functionality provided by LOCAL_APIC, while
legacy PIC doesn't
provide this(correct?).

If so,  it really makes sense to enable IRQ_WORK only when X86_LOCAL_APIC,
and I think we should make CONFIG_IRQ_WORK depend on this.

> The code is correct as is and there is no reason to shuffle it in circles for
> no value.

Will the below layout make sense?

*  Layout:
*  0xff, 0xfe:
*      Two highest vectors, granted for spurious vector and error vector.
*  0xfd - 0xf9:
*      CONFIG_SMP dependent vectors. On morden machines these are achieved
*      via local APIC, so these imply CONFIG_X86_LOCAL_APIC.
*
*  0xf8 - 0xf0:
*      CONFIG_X86_LOCAL_APIC dependent vectors, but these do not necessarily
*      depend on CONFIG_SMP, so are seperated from above.
*      Some are only depending on CONFIG_X86_LOCAL_APIC, but some are depending
*      on more(MCE, Virtualization, etc).
*
*     Note:  CONFIG_IRQ_WORK replies on CONFIG_X86_LOCAL_APIC(for self
IPI),  though it could
*                 be turned on  ! CONFIG_X86_LOCAL_APIC.
*  0xef:
*      Local APIC timer vector.

Regards,
Jianyu Zhan