From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1767611AbXDFNPI (ORCPT ); Fri, 6 Apr 2007 09:15:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1767613AbXDFNPI (ORCPT ); Fri, 6 Apr 2007 09:15:08 -0400 Received: from amsfep15-int.chello.nl ([62.179.120.10]:63729 "EHLO amsfep15-int.chello.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752810AbXDFNPG (ORCPT ); Fri, 6 Apr 2007 09:15:06 -0400 Subject: Re: Shared futexes (was [PATCH] FUTEX : new PRIVATE futexes) From: Peter Zijlstra To: Hugh Dickins Cc: Eric Dumazet , Ulrich Drepper , Andrew Morton , Dave Jones , Nick Piggin , Ingo Molnar , Andi Kleen , Ravikiran G Thirumalai , "Shai Fultheim (Shai@scalex86.org)" , pravin b shelar , linux-kernel@vger.kernel.org, "Pierre.Peiffer" In-Reply-To: References: <20060808070708.GA3931@localhost.localdomain> <200608090826.28249.dada1@cosmosbay.com> <200608090843.52893.dada1@cosmosbay.com> <200703152010.35614.dada1@cosmosbay.com> <20070405194942.1414c030.dada1@cosmosbay.com> <1175862369.6483.173.camel@twins> Content-Type: text/plain Date: Fri, 06 Apr 2007 15:15:00 +0200 Message-Id: <1175865300.6483.183.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2007-04-06 at 14:02 +0100, Hugh Dickins wrote: > On Fri, 6 Apr 2007, Peter Zijlstra wrote: > > > > some thoughts on shared futexes; > > > > Could we get rid of the mmap_sem on the shared futexes in the following > > manner: > > > > - do a page table walk to find the pte; > > ("walk" meaning descent down the levels, I presume, rather than across) indeed. > I've not had time to digest your proposal, and I'm about to go out: > let me sound a warning that springs to mind, maybe it's entirely > inapproriate, but better said than kept silent. > > It looks as if you're supposing that mmap_sem is needed to find_vma, > but not for going down the pagetables. It's not a simple as that: > you need to be careful that a concurrent munmap from another thread > isn't freeing pagetables from under you. > > Holding (down_read) of mmap_sem is one way to protect against that. > try_to_unmap doesn't have that luxury: in its case, it's made safe > by the way free_pgtables does anon_vma_unlink and unlink_file_vma > before freeing any pagetables, so try_to_unmap etc. won't get there; > but you can't do that. Ah, drad. I had hoped that the pte_lock would solve that race, but that doesn't cover the upper levels of the tree. Back to the drawing board..