Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752922AbbBKNPf (ORCPT ); Wed, 11 Feb 2015 08:15:35 -0500 Received: from cantor2.suse.de ([195.135.220.15]:46498 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990AbbBKNPe (ORCPT ); Wed, 11 Feb 2015 08:15:34 -0500 Date: Wed, 11 Feb 2015 14:15:28 +0100 (CET) From: Jiri Kosina X-X-Sender: jikos@twin.jikos.cz To: Linus Torvalds cc: Torvald Riegel , LKML , Ingo Molnar Subject: Re: POSIX mutex destruction requirements vs. futexes In-Reply-To: Message-ID: References: <1417098455.1771.338.camel@triegel.csb> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1425 Lines: 40 On Thu, 27 Nov 2014, Linus Torvalds wrote: > On Thu, Nov 27, 2014 at 6:27 AM, Torvald Riegel wrote: > > > > Using reference-counting in critical sections to decide when the mutex > > protecting the critical section can be destroyed has been recently > > discussed on LKML. For example, something like this is supposed to > > work: > > > > int free = 0; > > > > mutex_lock(&s->lock); > > if (--s->refcount == 0) > > free = 1 > > mutex_unlock(&s->lock); > > if (free) > > kfree(s); > > Yeah, this is a nasty case. We've had this bug in the kernel, and only > allow self-locking data structures with spinlocks (in which the unlock > operation is guaranteed to release the lock and never touch the data > structure afterwards in any way - no "unlock fastpath followed by > still touching it"). BTW, is this even documented anywhere? I don't think we can easily perform any runtime checks on this potentially pathological pattern (say, in lockdep), but I think we are clearly not even properly documenting it anywhere (at least Documentation/locking/mutex-design.txt doesn't mention it at all). -- Jiri Kosina SUSE Labs -- 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/