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]

Date:	Mon, 5 May 2008 08:57:57 -0700
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	Frans Pop <elendil@...net.nl>
Cc:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>,
	"Packard, Keith" <keith.packard@...el.com>
Subject: Re: [git head] Should X86_PAT really default to yes?

On Sunday, May 04, 2008 12:10 am Frans Pop wrote:
> On Friday 02 May 2008, Jesse Barnes wrote:
> > This is just a transient issue during VT switch or server exit though,
> > right? X functionality isn't affected, and your VTs work fine?
>
> Transient only. I've just tested again and this time the band
> was visible on top of the text on VT1 for about 2 seconds. Then it
> disappeared.
> The artifacts also appear when I log out from KDE (i.e. without exiting the
> server), and I also get the messages when logging out and logging in again.
>
> I do not see any performance issues, but I've only used this kernel for a
> very short time.
>
> > If so, it might not be a PAT issue but just a different memory layout or
> > something (and therefore it would really just be a cosmetic bug in the X
> > driver).
>
> The artifacts may not be a PAT issue directly, but it is a clear regression
> for me as I currently have a nice clean screen when X shuts down. I'm also
> 100% sure that it is caused by enabling PAT. A kernel with same config and
> only PAT disabled does not show the artifacts.
>
> Would you like me to file a bug against X for these artifacts?
> If so, against what component? The i810 driver or the server?

I suspect an i810 driver bug is being uncovered here, since we do have 
transient VT switch corruption on some other platforms (we're just exposing 
our chip reprogramming on the screen, rather than keeping it off the whole 
time).  But there could also be something PAT specific going on, I'll have to 
walk through those code paths...

> Also attached a dmesg that shows the messages. As you can see there are
> some repeats.
> - first 22 "expected mapping type" when X is started
> - second 22 "expected mapping type" when logging in
> - 9 "freeing invalid memtype" when logging out
> - 22 "expected mapping type" when logging in again
> - 9 "freeing invalid memtype" when logging out again
> - last series "expected mapping type" when restarting X server
>
> I must say that I'm fairly disappointed by your (plural) attitude to these
> regressions, especially given that you both seem to feel it is important
> that people will actually use PAT.

Oh the messages should be removed or somehow minimized, I agree.  I'm just not 
sure if the other bug is serious enough to block PAT by default yet, but 
either way we should fix the bugs!

> That said, I'll be happy to help trace and get these issues fixed.

Thanks for your help so far...

Jesse
--
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/