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 11:21:49 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Jiang Liu <jiang.liu@...ux.intel.com>
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 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.

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