linux-kernel - Re: [PATCH] x86: create array based interface to change page attribute

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] [day] [month] [year] [list]

Date:	Tue, 8 Apr 2008 07:27:27 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Thomas Hellström <thomas@...gstengraphics.com>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Andi Kleen <andi@...stfloor.org>,
	Dave Airlie <airlied@...hat.com>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH] x86: create array based interface to change page attribute

On Monday, April 07, 2008 11:21 pm Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Monday, April 07, 2008 1:46 pm Thomas Hellström wrote:
> >>> Why would we need to flush at all at unbind-read-bind time?  We should
> >>> be able to leave pages in the WC state even when we unbind them, then
> >>> when we need to bind them back into the GTT they'll be ready, but maybe
> >>> I'm misunderstanding you here...
> >>
> >> We want to make the user-space mapping cache-coherent after unbind
> >> during read, to have any serious read-speed, and the linear kernel map
> >> has to follow, unless it's non-present. Even if it's non present, we
> >> need to flush whatever was written through the user-space mapping from
> >> the cache when rebinding. Having the user-space mapping read-only when
> >> possible will help avoid this.
> >
> > Ah, you actually want to *read* from memory?  Yeah that would be really
> > slow if we left it UC or WC.  But I thought that was really only
> > necessary for relocation, and keithp dealt with that with the "presumed
> > offset" stuff?  Are you seeing other cases where we need to read back
> > frequently?
>
> While keithp's "presumed offset" is really good stuff, we should never
> need to read from device memory during relocations, I think. I was
> thinking of EXA and OpenGL software fallback cases, "download from
> screen" and "readpixels" types of operation, as well as
> pixel-buffer-object map in read mode.

Hm, yeah, anholt was telling me about some of these cases offline too.  This 
is what makes things really difficult...

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/