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]

Date:	Mon, 7 Apr 2008 12:59:19 -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 12:51 pm Thomas Hellström wrote:
> > Hopefully the WC stuff will be upstream right after 2.6.25 comes out. 
> > Any reason why we shouldn't keep the pages mapped in the kernel as WC
> > assuming the interface is there?
>
> If the pages are unmapped, we can get reasonable speed doing
> unbind-read-bind operations, kernel accesses to the memory will need to
> use an iomap_atomic_prot_pfn() type of operation.
> No IPI global tlb flushes needed for kernel mapping changes during
> unbind-read-bind and no cache flushes needed either if we write-protect
> the user-space mappings properly, or very limited cache flushes if we
> keep dirty-written-while-cached flags for each page.
>
> If the pages are wc-d we'll need two extra IPI global tlb flushes and a
> buffer-size cache flush every time we do unbind-read-bind, but OTOH we
> don't need the iomap_atomic_prot_pfn() to access single pages from the
> kernel.

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

> > Also, to make the API readable, we'd probably want to split the function
> > into kernel_map_pages(..., enum memory_type type) and
> > kernel_unmap_pages(...) (though like I said I think we really should be
> > mapping them WC not umapping them altogether, since we do want to hit the
> > ring buffer from the kernel with the WC type for example).
>
> I think ring-buffers are using ioremap() or vmap() already today. We can
> use these to get WC-type access also in the future. The only time we use
> the linear kernel mapping today is for single page access while patching
> up command buffers.

Yeah, they're ioremapped now, but that's a problem since with the PAT patches 
they'll be mapped hard UC (right now it just happens to work).

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