Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269441AbUIYXof (ORCPT ); Sat, 25 Sep 2004 19:44:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269442AbUIYXoc (ORCPT ); Sat, 25 Sep 2004 19:44:32 -0400 Received: from mx1.redhat.com ([66.187.233.31]:24277 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S269441AbUIYXoW (ORCPT ); Sat, 25 Sep 2004 19:44:22 -0400 Date: Sat, 25 Sep 2004 19:44:05 -0400 (EDT) From: Rik van Riel X-X-Sender: riel@chimarrao.boston.redhat.com To: Andrea Arcangeli cc: "Martin J. Bligh" , Andrew Morton , Subject: Re: ptep_establish/establish_pte needs set_pte_atomic and all set_pte must be written in asm In-Reply-To: <20040925155404.GL3309@dualathlon.random> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1031 Lines: 34 On Sat, 25 Sep 2004, Andrea Arcangeli wrote: > set_pte), while something like this should be fine: > > ptep_get_and_clear > set_pte > flush_tlb Almost. Think of software TLB refills, especially HPTE. The order needs to be: ptep_get_and_clear flush_tlb set_pte Any page faults happening "in the middle" will end up as virtual no-ops once they grab the page_table_lock. Luckily the PPC64 code in 2.6 seems to have a fix for the race already. Martin's race is a 2.4 thing only and needs a 2-line change to establish_pte(), to make the code do what I described above. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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/