Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262412AbUKDTqt (ORCPT ); Thu, 4 Nov 2004 14:46:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262403AbUKDTqQ (ORCPT ); Thu, 4 Nov 2004 14:46:16 -0500 Received: from mx2.elte.hu ([157.181.151.9]:11495 "EHLO mx2.elte.hu") by vger.kernel.org with ESMTP id S262412AbUKDTnO (ORCPT ); Thu, 4 Nov 2004 14:43:14 -0500 Date: Thu, 4 Nov 2004 20:44:16 +0100 From: Ingo Molnar To: john cooper Cc: Mark_H_Johnson@raytheon.com, Karsten Wiese , Bill Huey , Adam Heath , "K.R. Foley" , linux-kernel@vger.kernel.org, Florian Schmidt , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Thomas Gleixner , Michal Schmidt Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Message-ID: <20041104194416.GC10107@elte.hu> References: <20041104163012.GA3498@elte.hu> <20041104163254.GA3810@elte.hu> <418A7BFB.6020501@timesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <418A7BFB.6020501@timesys.com> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1136 Lines: 25 * john cooper wrote: > > plus there's the 'priority inheritance dependency-chain closure' bug > > noticed by John Cooper - that should only affect the latency of RT > > tasks though. > > This is a fairly gnarly problem to address. The obvious solution is > to hold spinlocks in the mutexes as the dependency tree is atomically > traversed. However this will deadlock under MP due to the > unpredictable order of mutexes traversed. If the dependency chain is > not traversed (and semantics applied) atomically, races exist which > cause promotion decisions to be made on [now] stale data. is the order of locks in the dependency chain really unpredictable? If two chain walkers get two locks in opposite order, doesnt that mean that the lock ordering (as attempted by the blocked tasks) is deadlock-prone already? I.e. this scenario should not happen. Ingo - 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/