linux-kernel - [PATCH} 2.6.24-rc8-mm1 - x86_64 PAT issues with vesafb and NVidia cards

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: <7567.1200941586@turing-police.cc.vt.edu>
Date:	Mon, 21 Jan 2008 13:53:06 -0500
From:	Valdis.Kletnieks@...edu
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Gerd Knorr <kraxel@...esex.org>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH} 2.6.24-rc8-mm1 - x86_64 PAT issues with vesafb and NVidia cards

(Gerd Knorr cc'ed because 'git blame' says he last touched the line of code
I ended up touching - if this needs other cc:'s, will somebody who knows who
should review please add them?)

On Thu, 17 Jan 2008 02:35:14 PST, Andrew Morton said: 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/

This gave the NVidia binary driver indigestion:

X:2772 conflicting cache attribute d0000000-d0006000 uncached<->default

While researching this one and adding some debugging printk's and dump_stack()s,
I found that this was caused by:

[    0.444051] reserve_mattr swapper:1  setting d0000000-d0500000 to default
[    0.444055] Pid: 1, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[    0.444057]
[    0.444057] Call Trace:
[    0.444065]  [<ffffffff8034dfe7>] ? ioremap_page_range+0x17b/0x244
[    0.444069]  [<ffffffff802259ba>] reserve_mattr+0x91/0x27d
[    0.444072]  [<ffffffff80224c24>] __ioremap+0xe6/0x146
[    0.444077]  [<ffffffff806f7297>] vesafb_probe+0x196/0x6b2
...

So the vesafb driver had decided to tag an even *larger* space as 'default'..
I'm *guessing* that in fact, this area should have been non-caching (since
it's the video memory for the card), but nothing cared/flagged before.

Pigheaded-and-probably-wrong brute-force fix that works on my laptop, but
somebody who actually understands the vesafb code should check that in fact
the space *should* be non-caching.

Signed-off-by: Valdis Kletnieks <valdis.kletnieks@...edu>

--- linux-2.6.24-rc8-mm1/drivers/video/vesafb.c.dist	2007-10-09 16:31:38.000000000 -0400
+++ linux-2.6.24-rc8-mm1/drivers/video/vesafb.c	2008-01-20 11:11:57.000000000 -0500
@@ -286,7 +286,7 @@ static int __init vesafb_probe(struct pl
 	info->pseudo_palette = info->par;
 	info->par = NULL;
 
-	info->screen_base = ioremap(vesafb_fix.smem_start, vesafb_fix.smem_len);
+	info->screen_base = ioremap_nocache(vesafb_fix.smem_start, vesafb_fix.smem_len);
 	if (!info->screen_base) {
 		printk(KERN_ERR
 		       "vesafb: abort, cannot ioremap video memory 0x%x @ 0x%lx\n",



Content of type "application/pgp-signature" skipped