Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751140AbaJZHnI (ORCPT ); Sun, 26 Oct 2014 03:43:08 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:48004 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbaJZHnG (ORCPT ); Sun, 26 Oct 2014 03:43:06 -0400 Date: Sun, 26 Oct 2014 08:42:57 +0100 From: Peter Zijlstra To: Thomas Gleixner Cc: Chris Friesen , rt-users , LKML , Steven Rostedt Subject: Re: semantics of reader/writer semaphores in rt patch Message-ID: <20141026074257.GC10501@worktop.programming.kicks-ass.net> References: <544956B8.2000406@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 26, 2014 at 12:21:31AM +0200, Thomas Gleixner wrote: > On Sun, 26 Oct 2014, Thomas Gleixner wrote: > > On Thu, 23 Oct 2014, Chris Friesen wrote: > > > Does the RT kernel just disallow this sort of algorithm? > > > > Yes. For a good reason. Let's add thread C > > > > A B C > > down_read(X) > > down_write(X) > > lock(Y) > > modify data > > unlock(Y) > > wake(B) > > down_read(X) > > > > Due to the mainline rwsem fairness semantics: > > > > A holds X, C is blocked on A and B is blocked on A. > > > > Deadlock, without RT and the single reader restriction being involved. > > > > So RT does not violate ANY of the existing mainline semantics, it just > > imposes a performance impact of not allowing multiple readers. > > @peterz: It might be worthwhile to have a CONFIG_LOCKDEP=y dependent > mode which restricts concurrent readers to 1 in mainline to catch this > kind of stuff. Hmm? There were patches by ego that fix lockdep's read side tracking. I need to find a few spare days to look at those :/ -- 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/