Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268157AbUJOQu4 (ORCPT ); Fri, 15 Oct 2004 12:50:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268175AbUJOQu4 (ORCPT ); Fri, 15 Oct 2004 12:50:56 -0400 Received: from bi01p1.co.us.ibm.com ([32.97.110.142]:34510 "EHLO linux.local") by vger.kernel.org with ESMTP id S268157AbUJOQul (ORCPT ); Fri, 15 Oct 2004 12:50:41 -0400 Date: Fri, 15 Oct 2004 09:45:43 -0700 From: "Paul E. McKenney" To: Ingo Molnar Cc: Dipankar Sarma , Sven Dietrich , Daniel Walker , Andrew Morton , linux-kernel@vger.kernel.org, abatyrshin@ru.mvista.com, amakarov@ru.mvista.com, emints@ru.mvista.com, ext-rt-dev@mvista.com, hzhang@ch.mvista.com, yyang@ch.mvista.com, "Witold. Jaworski@Unibw-Muenchen. De" , arnd.heursch@unibw-muenchen.de Subject: Re: [ANNOUNCE] Linux 2.6 Real Time Kernel Message-ID: <20041015164543.GA1725@us.ibm.com> Reply-To: paulmck@us.ibm.com References: <20041011215420.GA19796@elte.hu> <20041012055029.GB1479@elte.hu> <20041014050905.GA6927@in.ibm.com> <20041014071810.GB9729@elte.hu> <20041015145915.GA1266@us.ibm.com> <20041015154542.GA8257@elte.hu> <20041015164039.GA1265@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041015164039.GA1265@us.ibm.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1528 Lines: 33 On Fri, Oct 15, 2004 at 09:40:39AM -0700, Paul E. McKenney wrote: > On Fri, Oct 15, 2004 at 05:45:42PM +0200, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > One caution (which you are no doubt already aware of) -- if an RCU > > > algorithm that reads (rcu_read_lock()/rcu_read_unlock()) in process > > > context and updates in softirq/bh/irq context, you can see deadlocks. > > > > yeah - but in the PREEMPT_REALTIME kernel there are simply no irq or > > softirq contexts in process contexts - everything is a task. So > > everything can (and does) block. > > OK, am probably confused, but I thought that the whole point of your > PREEMPT_REALTIME implementation of rcu_read_lock_rt() was to enable > preemption in the RCU read-side critical section. If this is indeed > the case, then it looks to me like code that would run in softirq/bh/irq > context in a kernel compiled non-PREEMPT_REALTIME could now run during > the time that a code path running under rcu_read_lock_rt() was preempted. > > If so, then the kernel can end up freeing a data item that the preempted > RCU read-side critical section is still referencing. > > OK, so what am I missing here? Never mind!!! You insert the mutex. Sorry for the noise! Thanx, Paul - 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/