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

Message-ID: <47FB0EE8.30001@tungstengraphics.com>
Date:	Tue, 08 Apr 2008 08:21:28 +0200
From:	Thomas Hellström <thomas@...gstengraphics.com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
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

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.

/Thomas



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