Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751438AbWBQPrh (ORCPT ); Fri, 17 Feb 2006 10:47:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751506AbWBQPrg (ORCPT ); Fri, 17 Feb 2006 10:47:36 -0500 Received: from gateway-1237.mvista.com ([63.81.120.158]:9205 "EHLO hermes.mvista.com") by vger.kernel.org with ESMTP id S1751438AbWBQPrg (ORCPT ); Fri, 17 Feb 2006 10:47:36 -0500 Subject: Re: Robust futexes From: Daniel Walker To: Rusty Russell Cc: Ingo Molnar , lkml - Kernel Mailing List In-Reply-To: <1140152271.25078.42.camel@localhost.localdomain> References: <1140152271.25078.42.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 17 Feb 2006 07:47:34 -0800 Message-Id: <1140191254.3492.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 967 Lines: 24 On Fri, 2006-02-17 at 15:57 +1100, Rusty Russell wrote: > Hi Ingo, all, > > Noticed (via LWN, hence the delay) your robust futex work. Have you > considered the less-perfect, but simpler option of simply having futex > calls which tell the kernel that the u32 value is in fact the holder's > TID? > > In this case, you don't get perfect robustness when TID wrap occurs: > the kernel won't know that the lock holder is dead. However, it's > simple, and telling the kernel that the lock is the tid allows the > kernel to do prio inheritence etc. in future. I think this was Todd Kneisel's approach . His version was vma scanning, which is what Ingo is trying to replace. It just used the current u32 value . Daniel - 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/