linux-kernel - Re: [PATCH v6 04/12] x86/smpboot.c: Don't offline CPU0 if any irq can not be migrated out of it and remove CPU0 check in smp

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: <CA+8MBbJbEWTR2Tawa2SzcJ-mZSPzZ12a9usR5eQu=PhArZwXLA@mail.gmail.com>
Date:	Fri, 11 May 2012 11:42:18 -0700
From:	Tony Luck <tony.luck@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Fenghua Yu <fenghua.yu@...el.com>, Ingo Molnar <mingo@...e.hu>,
	H Peter Anvin <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Asit K Mallick <asit.k.mallick@...el.com>,
	Arjan Dan De Ven <arjan@...ux.intel.com>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Len Brown <len.brown@...el.com>,
	"Srivatssa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Chen Gong <gong.chen@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-pm <linux-pm@...r.kernel.org>, x86 <x86@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v6 04/12] x86/smpboot.c: Don't offline CPU0 if any irq can
 not be migrated out of it and remove CPU0 check in smp_callin()

On Fri, May 11, 2012 at 5:05 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> +     if (cpuid == 0)
>> +             identify_boot_cpu_online();
>
> No, this is not how we do things.
>
> If this is required, then hell we do it at boot time and not at a
> random place in the cpu hotplug code.

Open to better suggestions for placement.  Sometimes we do need
special cases because on x86 the system isn't symmetrical, cpu0
really is treated differently by h/w and f/w and we have to live with this.
Biggest code impact of that is the extra code to bring cpu0 back online
using NMI instead of INIT. We can't use INIT because if cpu0 gets one,
it just resets the whole machine :-(  But obviously we'd like to avoid
special cases where there is a sane way to do so.

> This is as fricking wrong as it gets. We already know that at boot
> time when we initialize the irq chips. There is no need to iterate
> over the whole irq descriptors just to figure that out.

We *knew* it at boot time ... but that information will be stale if
we hot plugged new devices and bound their interrupts to cpu0.

Do we need to maintain some parallel table of this information, or
is there a better way to check this?

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