Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762430AbXJES72 (ORCPT ); Fri, 5 Oct 2007 14:59:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752251AbXJES7U (ORCPT ); Fri, 5 Oct 2007 14:59:20 -0400 Received: from mx1.redhat.com ([66.187.233.31]:59656 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbXJES7T (ORCPT ); Fri, 5 Oct 2007 14:59:19 -0400 Date: Fri, 5 Oct 2007 14:58:28 -0400 From: Rik van Riel To: Hugh Dickins Cc: Jeremy Fitzhardinge , David Rientjes , Zachary Amsden , Andrew Morton , Linus Torvalds , Rusty Russell , Andi Kleen , Keir Fraser , Linux Kernel Mailing List Subject: Re: race with page_referenced_one->ptep_test_and_clear_young and pagetable setup/pulldown Message-ID: <20071005145828.17ba9c69@cuia.boston.redhat.com> In-Reply-To: References: <470596C4.8060804@goop.org> Organization: Red Hat, Inc X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1285 Lines: 31 On Fri, 5 Oct 2007 12:36:33 +0100 (BST) Hugh Dickins wrote: > To my naive mind, your problem actually lies in those two stages: > whatever marks the pages RO should not be keeping Xen in ignorance. It does. Telling Xen to pin the page as a page table page is basically the first thing a Xen kernel does after marking the page read-only. This makes for a narrow race window, during which ptep_test_and_clear_young cannot clear the referenced bit and may end up causing a crash. We do not care about it not clearing the referenced bit during that window, since it will be cleared during the next go-around and the race is very rare. Hence, the only thing we need to fix is the crash. We can do that by adding an entry for ptep_test_and_clear_young to the exception table. This way we do not need to turn this into a new paravirt ops hook (since the fast path is exactly the same as x86 native) and there is no need for added complexity. Also, Xen would not conflict with SPLIT_PTLOCK_CPUS. -- All Rights Reversed - 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/