From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761463AbYD2PPb (ORCPT ); Tue, 29 Apr 2008 11:15:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760238AbYD2PPK (ORCPT ); Tue, 29 Apr 2008 11:15:10 -0400 Received: from viefep18-int.chello.at ([213.46.255.22]:65285 "EHLO viefep19-int.chello.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757452AbYD2PPG (ORCPT ); Tue, 29 Apr 2008 11:15:06 -0400 Subject: Re: [PATCH 1/8] lockdep: fix recursive read lock validation From: Peter Zijlstra To: Bart Van Assche Cc: ego@in.ibm.com, linux-kernel@vger.kernel.org, Zdenek Kabelac , Oleg Nesterov , Heiko Carstens , "Rafael J. Wysocki" , Andrew Morton , Ingo Molnar , Srivatsa Vaddagiri In-Reply-To: References: <20080429125659.GA23562@in.ibm.com> <20080429125750.GB23562@in.ibm.com> <1209481050.13978.72.camel@twins> Content-Type: text/plain Date: Tue, 29 Apr 2008 17:15:01 +0200 Message-Id: <1209482101.13978.91.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2008-04-29 at 17:03 +0200, Bart Van Assche wrote: > On Tue, Apr 29, 2008 at 4:57 PM, Peter Zijlstra wrote: > > > > On Tue, 2008-04-29 at 15:16 +0200, Bart Van Assche wrote: > > > On Tue, Apr 29, 2008 at 2:57 PM, Gautham R Shenoy wrote: > > > > Subject: lockdep: fix recursive read lock validation > > > > This means that the following sequence is now invalid, whereas previously > > > > it was considered valid: > > > > > > > > rlock(a); rlock(b); runlock(b); runlock(a) > > > > rlock(b); rlock(a); > > > > > > Why are you marking this sequence as invalid ? Although it can be > > > debated whether it is good programming practice to be inconsistent > > > about the order of read-locking, the above sequence can't be involved > > > in a deadlock. > > > > Not for pure read locks, but when you add write locks to it, it does get > > deadlocky. Lockdep does not keep separate chains for read and write > > locks. > > Nesting writer locks inside reader locks is always a bad idea. So > please come up with an example of how varying the reader lock nesting > order can trigger a deadlock (when no writer locks are nested inside > reader locks and nested writer locks are always nested in the same > order). It can't deadlock when only readers are involved, but lockdep will not be able to distinguish between the cases where only read locks are involved and a mix of readers and writers is involved. Hence disallow both. But hitting this requiers you do a series of rather unfortunate things: 1) use recursive locking 2) don't have strict lock order 3) make it work by using read locks only Seriously, any code that triggers this might want to have its locking re-throught.