public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [git pull] x86 PAT changes
Date: Sat, 26 Apr 2008 10:56:00 +0200	[thread overview]
Message-ID: <20080426085600.GA5891@elte.hu> (raw)
In-Reply-To: <alpine.LFD.1.10.0804251808590.2813@woody.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, 25 Apr 2008, H. Peter Anvin wrote:
> > 
> > The problem is that that can create cached/uncached aliases, which 
> > can cause some processors to lock up (especially AMD is known to 
> > have a lot of errata in this area.)
> 
> Umm.. I don't think you understand. Right now, NONPROMISC_DEVMEM 
> doesn't just disable mmap() on /dev/mem, it disables totally regular 
> reads and writes too. That seems pretty damn excessive.
> 
> If it was just mmap(), I don't think it would matter much. I don't 
> think we traditionally even supported mmap() on real RAM (because the 
> page counting would get confused), and that actually got supported 
> only thanks to VM changes that made it possible.
> 
> But read/write has always been supported, and shouldn't cause any 
> cached/uncached aliases!

You are right, there should be no architectural need to make PAT 
dependent on nonpromisc-devmem, and thus the patch below should be safe.

In theory even mmap() of /dev/mem should be safe this way - as all 
memtypes are properly tracked.

The thinking behind this dependency was three-fold:

- historic: from the days when the PAT patchset didnt do fully correct 
  tracking yet

- practical: that PAT would be utilized in newer distros on newer 
  systems - with older distros on older systems not really wanting 
  (or needing) neither /dev/mem restrictions nor PAT

- paranoia: one less degree of freedom to take into account

	Ingo

----------------------->
Subject: x86 PAT: decouple from nonpromisc devmem
From: Ingo Molnar <mingo@elte.hu>
Date: Sat Apr 26 10:26:52 CEST 2008

Linus pointed it out that PAT should not depend on NONPROMISC_DEVMEM.

Also make PAT non-default.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-x86.q/arch/x86/Kconfig
===================================================================
--- linux-x86.q.orig/arch/x86/Kconfig
+++ linux-x86.q/arch/x86/Kconfig
@@ -1042,9 +1042,9 @@ config MTRR
 	  See <file:Documentation/mtrr.txt> for more information.
 
 config X86_PAT
-	def_bool y
+	bool
 	prompt "x86 PAT support"
-	depends on MTRR && NONPROMISC_DEVMEM
+	depends on MTRR
 	help
 	  Use PAT attributes to setup page level cache control.
 

  reply	other threads:[~2008-04-26  8:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-24 22:56 [git pull] x86 PAT changes Ingo Molnar
2008-04-25 23:43 ` Linus Torvalds
2008-04-26  0:06   ` H. Peter Anvin
2008-04-26  1:12     ` Linus Torvalds
2008-04-26  8:56       ` Ingo Molnar [this message]
2008-04-26 16:54         ` Pallipadi, Venkatesh
2008-04-26 17:15           ` Linus Torvalds
2008-04-26 18:32             ` Venki Pallipadi
2008-04-26 19:07               ` [patch] x86, PAT: disable /dev/mem mmap RAM with PAT Ingo Molnar
2008-04-26  9:57   ` [git pull] x86 PAT changes Ingo Molnar
2008-04-26 13:40 ` Gabriel C
2008-04-26 14:42   ` Ingo Molnar
2008-04-26 15:37     ` Gabriel C
2008-04-26 15:41       ` Ingo Molnar
2008-04-26 16:43         ` Linus Torvalds

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=20080426085600.GA5891@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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