linux-kernel - RE: [git head] Should X86_PAT really default to yes?

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: <924EFEDD5F540B4284297C4DC59F3DEEFB8E83@orsmsx423.amr.corp.intel.com>
Date:	Fri, 2 May 2008 14:55:57 -0700
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	"Barnes, Jesse" <jesse.barnes@...el.com>
Cc:	"Frans Pop" <elendil@...net.nl>, <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Packard, Keith" <keith.packard@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: RE: [git head] Should X86_PAT really default to yes?

 

>-----Original Message-----
>From: Barnes, Jesse 
>Sent: Friday, May 02, 2008 1:40 PM
>To: Pallipadi, Venkatesh
>Cc: Frans Pop; linux-kernel@...r.kernel.org; Ingo Molnar; 
>Packard, Keith
>Subject: Re: [git head] Should X86_PAT really default to yes?
>
>On Friday, May 02, 2008 12:37 pm Pallipadi, Venkatesh wrote:
>> >-----Original Message-----
>> >From: Frans Pop [mailto:elendil@...net.nl]
>> >Sent: Friday, May 02, 2008 12:22 PM
>> >To: linux-kernel@...r.kernel.org
>> >Cc: Pallipadi, Venkatesh; Ingo Molnar
>> >Subject: [git head] Should X86_PAT really default to yes?
>> >
>> >With X86_PAT enabled, when X is started I get about 40 lines
>> >(with varying
>> >addresses) like:
>> >kernel: Xorg:3358 /dev/mem expected mapping type write-back for
>> >807bf000-81000000, got uncached-minus
>
>These messages?  They're coming from the kernel it looks like, 
>from the 
>map_devmem routine in pat.c.  I'm not sure they're accurate 
>though; for PCI 
>regions /dev/mem is *supposed* to map with UC- and not WB, so 
>maybe this 
>function needs to be updated?
>

Indeed.
I think these messages are due to X using the mprotect workaround to
change UC_MINUS to WB.
I don't see these error messages on my 965 here. May be I have different
x version.

What may be happening:
1) process A mmaps /dev/mem and gets UC_MINUS
2) Changes the page table to make pg_prot WB
3) Does a fork to create process B
4) While copying the vma, we go through map_devmem request WB, but get
UC_MINUS back
5) We are not changing vma pg_prot to new value at this point (we should
change this), so one more round of errors will be there when forked
process exits.

Again, this should not have any side-effect like the band etc. It just a
"friendly warning". It should go away when X moves to using WC or does
not use the mprotect workaround to make pg_prot WB.

Thanks,
Venki
--
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/