On Thu, 27 Nov 2014, Linus Torvalds wrote: > On Thu, Nov 27, 2014 at 6:27 AM, Torvald Riegel <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
