Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753998AbZIUVS5 (ORCPT ); Mon, 21 Sep 2009 17:18:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753659AbZIUVS5 (ORCPT ); Mon, 21 Sep 2009 17:18:57 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:47358 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752289AbZIUVS4 (ORCPT ); Mon, 21 Sep 2009 17:18:56 -0400 Subject: Re: [PATCH] ib-release-locks-in-the-proper-order From: Steven Rostedt To: John Kacur Cc: mingo@elte.hu, Roland Dreier , Sean Hefty , Hal Rosenstock , tglx@linutronix.de, Peter Zijlstra , linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 21 Sep 2009 17:17:47 -0400 Message-Id: <1253567867.2935.4.camel@frodo> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1652 Lines: 52 On Mon, 2009-09-21 at 21:35 +0200, John Kacur wrote: > Please consider the following patch - originally from Steven Rostedt. > It solves a problem for rt which is very sensitive to the lock ordering. > It should have a no impact on non-rt. > > The patch applies to current tip/master - but it is fine with me if it > would be more appropriate for one of the infiniband people to take it. > > Thanks > > >From e533f2b9ee9b0bd95aaa4c3369e79b350c9895d3 Mon Sep 17 00:00:00 2001 > From: Steven Rostedt > Date: Mon, 21 Sep 2009 21:23:46 +0200 > Subject: [PATCH] ib: release locks in the proper order > > RT is very sensitive to the order locks are taken and released > wrt read write locks. We must do > > lock(a); > lock(b); > lock(c); > > [...] > > unlock(c); > unlock(b); > unlock(a); > > otherwise bad things can happen. > > Signed-off-by: Ken Cox > Signed-off-by: Clark Williams > Signed-off-by: John Kacur The -rt patch doesn't use the multi rwlock code anymore (the reason for the first patch), and the last revision of that code was able to handle that too. Linus totally ripped into this idea. A lock must be able to handle any order of unlocking. There should be no technical reason a lock must be unlocked in reverse order they were locked. What exactly is sensitive about this? -- Steve -- 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/