linux-kernel - RE: [PATCH v5 03/12] x86/topology.c: Support functions for CPU0 online/offline

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: <3E5A0FA7E9CA944F9D5414FEC6C7122003476A@ORSMSX105.amr.corp.intel.com>
Date:	Tue, 24 Jan 2012 23:00:25 +0000
From:	"Yu, Fenghua" <fenghua.yu@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	H Peter Anvin <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Luck, Tony" <tony.luck@...el.com>,
	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Brown, Len" <len.brown@...el.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	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>
Subject: RE: [PATCH v5 03/12] x86/topology.c: Support functions for CPU0
 online/offline

> > Quote from https://www.linux.com/how-to-participate-in-the-linux-
> community
> > "It can be tempting to add a whole new infrastructure with a series
> of
> > patches, but to leave that infrastructure unused until the final
> patch
> > in the series enables the whole thing. This temptation should be
> > avoided if possible; if that series adds regressions, bisection will
> > finger the last patch as the one which caused the problem, even
> though
> > the real bug is elsewhere. Whenever possible, a patch which adds new
> > code should make that code active immediately."
> >
> > So this patch currently is in the right place in the patch set unless
> > I miss something.
> 
> You're giving undue weight to that guidance.  It is far more important
> that you do not enable features that don't work!

Either way has reasonable arguments. This should be a generic question. But for this specific patch set, the above quote does make more sense to me as far as git bisect is concerned. Maybe someone else in the list can provide more insight?

Thanks.

-Fenghua