Date: Fri, 25 Jan 2008 16:30:32 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Harvey Harrison <harvey.harrison@gmail.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Andi Kleen <ak@suse.de>
Subject: Re: [PATCH UPDATE] x86: ignore spurious faults
Message-ID: <20080125153032.GE11846@elte.hu>
References: <4797D64D.1060105@goop.org> <1201133916.16972.124.camel@brick> <4797DBA0.5020909@goop.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4797DBA0.5020909@goop.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1203
Lines: 27


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> When changing a kernel page from RO->RW, it's OK to leave stale TLB 
> entries around, since doing a global flush is expensive and they pose 
> no security problem.  They can, however, generate a spurious fault, 
> which we should catch and simply return from (which will have the 
> side-effect of reloading the TLB to the current PTE).
>
> This can occur when running under Xen, because it frequently changes 
> kernel pages from RW->RO->RW to implement Xen's pagetable semantics. 
> It could also occur when using CONFIG_DEBUG_PAGEALLOC, since it avoids 
> doing a global TLB flush after changing page permissions.

thanks, applied.

it would be nice to expose this ability of the architecture to the core 
Linux kernel mprotect code as well, and let it skip on a TLB flush when 
doing a RO->RW transition. It could speed up valgrind and the other 
mprotect() users i guess? [and UML too perhaps]

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/