linux-kernel - Re: [tip:x86/bsp-hotplug] x86, apic: Disable BSP if boot cpu is AP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Nov 2013 19:20:14 +0900
From:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, hpa@...ux.intel.com,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/bsp-hotplug] x86, apic: Disable BSP if boot cpu is AP

(2013/11/12 4:54), H. Peter Anvin wrote:
> On 10/12/2013 10:42 AM, Ingo Molnar wrote:
>>
>> * H. Peter Anvin <hpa@...or.com> wrote:
>>
>>> On 10/09/2013 04:16 PM, tip-bot for HATAYAMA Daisuke wrote:
>>>> Commit-ID:  1d79e607332d67d9132c176d99b5e7fabe1b6b7f
>>>> Gitweb:     http://git.kernel.org/tip/1d79e607332d67d9132c176d99b5e7fabe1b6b7f
>>>> Author:     HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
>>>> AuthorDate: Thu, 29 Aug 2013 18:28:04 +0900
>>>> Committer:  H. Peter Anvin <hpa@...ux.intel.com>
>>>> CommitDate: Wed, 9 Oct 2013 15:41:11 -0700
>>>>
>>>> x86, apic: Disable BSP if boot cpu is AP
>>>
>>> This patch seems to trigger build failures in some configurations.
>>> Specifically:
>>>
>>> (.init.text+0x1307): undefined reference to `boot_cpu_is_bsp_init'
>>>
>>> Unfortunately I don't have the specific configuration which triggers the
>>> failure, as this was discovered by Fengguang's robot.
>>
>> I have triggered that too and have such a config, it's attached.
>
> Okay, thinking about this again, this patchset is in fact broken on:
>
> 1. Any configuration which has CONFIG_SMP=n and CONFIG_X86_UP_APIC=n.
>
> This is a built-time problem.
>
> 2. Any CPU which is old enough that MSR_IA32_APICBASE doesn't exist.
>
> This is a fatal runtime bug.
>
> 3. Any clustered solution which involves a third-party cluster
> controller such that MSR_IA32_APICBASE may not reflect the reality of
> the system.
>
> This is a less critical issue as "all" it ought to make happen is to
> disable some CPUs which didn't need it.
>
> Hatayama-san, you got this build bug report almost a month ago.  It
> looks like it is going to need a fair bit of cleanup, so I fear this is
> going to be dropped for v3.13.
>
> 	-hpa
>

Thanks for pointing out that. I think the first two issues has already been
fixed in v3 version. I've just posted v5 version a little time ago. BTW,
I changed the basic design at v4 where we specify the initial APIC ID of the
processor we want to disable in the kdump 2nd kernel from the the 1st kernel
through newly introduced disable_cpu_apicid kernel parameter; it might be
similar to the idea you described in the patch description of tip tree.

I don't know the third issue. Could you explain what kind of things can happen
on clustered system? Only IA32_APIC_BASE MSR is no longer trusted? Or are
there other things we can possibly no longer trust?

Also, could you explain what you suggest to deal with the issue in more detail?

-- 
Thanks.
HATAYAMA, Daisuke

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