public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: "Ozan Çağlayan" <ozan@pardus.org.tr>,
	"Yinghai Lu" <yinghai@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	mingo@elte.hu, a.p.zijlstra@chello.nl, stable@kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jaswinder Singh Rajput" <jaswinder@kernel.org>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Thomas Gleixner" <tglx@linutronix.de>
Subject: RFC: deprecate CONFIG_X86_CPU_DEBUG and schedule it for rapid removal
Date: Sun, 17 Jan 2010 17:26:53 -0800	[thread overview]
Message-ID: <4B53B8DD.9000809@zytor.com> (raw)
In-Reply-To: <201001171444.14551.rjw@sisk.pl>

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

CONFIG_X86_CPU_DEBUG really seems to be causing more problems than it
ever solved.  This is an RFC for immediately deprecating it, and
schedule it for removal in the 2.6.34 cycle.

If this was a high value feature, it would be different -- but it's not
even close.

Posting this as an RFC just on the offchance someone actually depends on
this.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-x86-Mark-CONFIG_X86_CPU_DEBUG-for-rapid-deprecation.patch --]
[-- Type: text/x-patch; name="0001-x86-Mark-CONFIG_X86_CPU_DEBUG-for-rapid-deprecation.patch", Size: 2926 bytes --]

>From 0a7c8171aa6d0aed1eda3902f675eb9a259d4cde Mon Sep 17 00:00:00 2001
From: H. Peter Anvin <hpa@zytor.com>
Date: Sun, 17 Jan 2010 17:05:59 -0800
Subject: [PATCH] x86: Mark CONFIG_X86_CPU_DEBUG for rapid deprecation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

The CONFIG_X86_CPU_DEBUG feature provides for a filesystem view of
some x86 CPU state in debugfs.  However, all this information is
already available to userspace via dedicated interfaces, and this
could just as easily be done in pure userspace.

It wouldn't be a problem, per se, except that this code has caused
boot failures in real-world scenarios when people have enabled it, see
for example kernel bugzilla 15075.

This is a good example of why this kind of functionality has no
business being in the kernel in the first place.

Mark this code deprecated and schedule it for rapid removal.

Reported-by: Ozan Çağlayan <ozan@pardus.org.tr>
Signed-Off-By: H. Peter Anvin <hpa@zytor.com>
LKML-Reference: <4B4F1DE7.307@pardus.org.tr>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 Documentation/feature-removal-schedule.txt |    9 +++++++++
 arch/x86/Kconfig                           |    9 ++++++++-
 2 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 870d190..49aabf1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -493,3 +493,12 @@ Why:	These two features use non-standard interfaces. There are the
 Who:	Corentin Chary <corentin.chary@gmail.com>
 
 ----------------------------
+
+What:	Support for x86 debug information via debugfs (CONFIG_X86_CPU_DEBUG)
+When:	2.6.34
+Why:	This feature does not introduce any functionality that is not
+	available through pure userspace.  However, it has been known
+	to causeboot failures in some hardware configurations.
+
+Who:	H. Peter Anvin <hpa@zytor.com>
+
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3b2a5ac..eb1751d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -987,11 +987,18 @@ config X86_CPUID
 	  /dev/cpu/31/cpuid.
 
 config X86_CPU_DEBUG
-	tristate "/sys/kernel/debug/x86/cpu/* - CPU Debug support"
+	tristate "/sys/kernel/debug/x86/cpu/* - CPU Debug support (DEPRECATED)"
 	---help---
 	  If you select this option, this will provide various x86 CPUs
 	  information through debugfs.
 
+	  This feature is strongly deprecated.  It has been known to cause
+	  problems with some hardware configurations and does not
+	  provide any functionality that is not available through pure
+	  userspace means.  It will be removed in the near future.
+
+	  It is strongly recommended that you select N here.
+
 choice
 	prompt "High Memory Support"
 	default HIGHMEM4G if !X86_NUMAQ
-- 
1.6.2.5


  reply	other threads:[~2010-01-18  1:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13 18:51 Boot hangs after "Freeing initrd memory" with 2.6.31.11 Ozan Çağlayan
2010-01-14  6:58 ` Ozan Çağlayan
2010-01-14  7:43   ` Yinghai Lu
2010-01-14  7:48     ` Ozan Çağlayan
2010-01-14 10:35     ` Ozan Çağlayan
2010-01-14 13:08       ` Ozan Çağlayan
2010-01-14 13:36         ` Ozan Çağlayan
2010-01-16 12:28           ` Ozan Çağlayan
2010-01-16 22:12             ` Rafael J. Wysocki
2010-01-17  8:43               ` Ozan Çağlayan
2010-01-17 13:43                 ` Rafael J. Wysocki
2010-01-17  9:22               ` Ozan Çağlayan
2010-01-17 13:44                 ` Rafael J. Wysocki
2010-01-18  1:26                   ` H. Peter Anvin [this message]
2010-01-18 21:28                     ` RFC: deprecate CONFIG_X86_CPU_DEBUG and schedule it for rapid removal Rafael J. Wysocki
2010-01-23  0:53                     ` Andrew Morton
2010-01-23  1:05                       ` H. Peter Anvin
2010-01-23  1:20                         ` [stable] " Greg KH
2010-01-23  1:51                           ` H. Peter Anvin
2010-01-23  1:59                       ` Linus Torvalds
2010-01-23  5:22                         ` Ingo Molnar
2010-01-18  0:58             ` Boot hangs after "Freeing initrd memory" with 2.6.31.11 H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2010-01-23  2:34 RFC: deprecate CONFIG_X86_CPU_DEBUG and schedule it for rapid removal H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B53B8DD.9000809@zytor.com \
    --to=hpa@zytor.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=jaswinder@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=ozan@pardus.org.tr \
    --cc=rjw@sisk.pl \
    --cc=stable@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox