linux-kernel - Re: [patch 00/23] x86: Cleanup apic/ioapic/x2apic setup code

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:	Fri, 16 Jan 2015 18:35:53 +0800
From:	Jiang Liu <jiang.liu@...ux.intel.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Joerg Roedel <joro@...tes.org>, x86@...nel.org,
	Tony Luck <tony.luck@...el.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [patch 00/23] x86: Cleanup apic/ioapic/x2apic setup code

On 2015/1/16 18:21, Thomas Gleixner wrote:
> On Fri, 16 Jan 2015, Jiang Liu wrote:
>> On 2015/1/16 5:22, Thomas Gleixner wrote:
>>> While reviewing Jiangs interrupt remapping patch set, I had several
>>> serious WTF moments when trying to understand what that code is doing.
>>>
>>> The main issues I've seen are:
>>>
>>>     - Blindly copy and pasted code
>>>
>>>     - Random places which initialize bits and pieces
>>>
>>>     - Code which got mindlessly expanded with duct tape and glue
>>>       without considering readability and maintainability.
>>>
>>>     - Missing inline stubs which result in a ifdef nightmare
>>>
>>>     - Superflous inline stubs to artificially avoid sensible ifdefs
>>>
>>> The deeper I looked the more I started to get grumpy about that maze
>>> and finally sat down and cleaned it up seriously. One bug I fixed on
>>> the way (surprise, surprise) got folded into Jiangs series which is
>>> now in tip/x86/apic. The other one is not that crucial and cant be
>>> fixed in the previous code without adding more mess.
>>>
>>> The following patch series applies on top of tip/x86/apic. It cleans
>>> up and consolidates the apic/ioapic/x2apic setup functions.
>>>
>>> Please give it a proper review and testing.
>> Hi Thomas,
>>
>> Have done following test matrix:
>> 1) Hardware X2apic capable: yes, preenabled by BIOS: no,
>>    Kernel: x2apic capable smp
>> 1.1) boot: ok
>> 1.2) boot with "nox2apic": ok
>> 1.3) boot with "nointremap": ok with CPU in physical flat mode
>>
>> 2) Hardware X2apic capable: yes, preenabled by BIOS: no,
>>    Kernel: x2apic incapable smp
>> 2.1) boot: ok
>>
>> 3) Hardware X2apic capable: yes, preenabled by BIOS: yes
>> 3.1) x2apic capable kernel: ok
>> 3.2) x2apic incapable kernel: hang with a blank screen(panic)
>>    Kernel: x2apic capable smp
>>
>> 4) Hardware X2apic capable: no
>> 4.1) boot x2apic capable smp kernel: ok
>> 4.2) boot x2apic incapable up kernel: ok
>> 4.3) boot xen domain0 with x2apic capable smp kernel: ok
>>
>> 5) x86_32, UP, IO_APIC disabled
>> 5.1) boot: panic with following call stack:
>> do_ono_initcall()->APIC_init_uniprocessor()->setup_local_APIC().
>> I can't capture the full log message due to lack of serial console.
>> It seems we have trouble with:
>> early_initcall(APIC_init_uniprocessor);
> 
> Hmm, worked here. Lemme find some other machine.
Hi Thomas,
	X86_64 UP with IOAPIC enabled works here too. Not sure the panic
is caused by X86_32 or disabling of IOAPIC. I have no access to the
problematic system on weekend, so could only do more tests early next
week.
Thanks!
Gerry

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