linux-kernel - Re: [PATCH v6 2/3] x86, apic: Add disable_cpu

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] [day] [month] [year] [list]

Message-ID: <20131122015910.GB31921@redhat.com>
Date:	Thu, 21 Nov 2013 20:59:10 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
Cc:	hpa@...ux.intel.com, ebiederm@...ssion.com,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	bp@...en8.de, akpm@...ux-foundation.org, fengguang.wu@...el.com,
	jingbai.ma@...com
Subject: Re: [PATCH v6 2/3] x86, apic: Add disable_cpu_apicid kernel parameter

On Fri, Nov 22, 2013 at 09:42:28AM +0900, HATAYAMA Daisuke wrote:
> (2013/11/22 6:33), Vivek Goyal wrote:
> >On Thu, Nov 21, 2013 at 11:00:44AM +0900, HATAYAMA Daisuke wrote:
> >
> >[..]
> >>@@ -2122,6 +2129,19 @@ void generic_processor_info(int apicid, int version)
> >>  	bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> >>  				phys_cpu_present_map);
> >>
> >>+	if (disabled_cpu_apicid != BAD_APICID &&
> >>+	    disabled_cpu_apicid != boot_cpu_physical_apicid &&
> >
> >Hi Hatayama,
> >
> >So we are comparing disabled_cpu_apicid with boot_cpu_physical_apicid
> >to make sure that one can not disable the cpu we are booting on. Can
> >we just read the apic id of booting cpu in local variable and compare
> >against that?
> >
> >Something like as follows.
> >
> >	if (disabled_cpu_apicid != BAD_APICID &&
> >	    disabled_cpu_apicid == apicid &&
> >	    disabled_cpu_apicid != read_apic_id()) {
> >		/* Disable cpu */	
> >	}
> >
> >If above works, you will not need first patch in the series?
> >
> 
> Yes, I came up with the idea, too. But doing this means we leave two different
> ways boot_cpu_physical_apicid is used at boot, which seemed incomplete as a
> patch. Also, then we could even lost the reason why boot_cpu_physical_apicid
> exists.
> 
> But, it's true that the 1st patch causes one more reviewing point. I'll
> remove it and fix the 2nd patch just as you suggested here.

I would say that do the boot_cpu_physical_id related cleanup in a separate
series. If we keep this patch really simple without fear of breaking
anything else, acking and committing the patch becomes easier.

Feel free to post boot cpu related cleanup in a separate series.

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