Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753897AbXEaOx7 (ORCPT ); Thu, 31 May 2007 10:53:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752333AbXEaOxw (ORCPT ); Thu, 31 May 2007 10:53:52 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]:6059 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183AbXEaOxv (ORCPT ); Thu, 31 May 2007 10:53:51 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N6L6JncIpe7NESELer9JzmJSQ3xKOThMEiMx27/Pvedr8TYt2bE27z/3B7F9d5gX931o573rdOTHFgm+aL1Qs4WZrts9RPMf2rpN4WyYvwxTBRilxaIMT4vSlvYtMxyE0VyqXppIcyxz1DnO+TiUqon9818Vlk3sGk5ePvzhqRc= Message-ID: Date: Thu, 31 May 2007 07:53:49 -0700 From: "Ulrich Drepper" To: "Steven Rostedt" Subject: Re: [BUG] futex_unlock_pi() hurts my brain and may cause application deadlock Cc: "john stultz" , lkml , "Ingo Molnar" , "Thomas Gleixner" , "Sripathi Kodi" In-Reply-To: <1180574993.21781.22.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1180572567.6126.44.camel@localhost.localdomain> <1180574993.21781.22.camel@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1121 Lines: 23 On 5/30/07, Steven Rostedt wrote: > > if (!(uval & FUTEX_OWNER_DIED)) { > > pagefault_disable(); > > uval = futex_atomic_cmpxchg_inatomic(uaddr, current->pid, 0); > > pagefault_enable(); > > } > [...] > This code is in futex_unlock_pi. Can the owner of the mutex really die? > Isn't the owner the one doing the unlock? This is part of the implementation of robust PI futexes. The semantics is that if the owner of a robust futex dies the futex is marked with FUTEX_OWNER_DIED. The next locking thread then has to clear that bit before calling pthread_mutex_unlock. If the bit is still set while unlocking the mutex is permanently marked unusable. I cannot say right now whether this is the semantics implemented above. I'll have to check the glibc test suite whether we check for that semantic. - 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/