Messages in this thread | | | Date | Fri, 15 Oct 2004 09:40:39 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [ANNOUNCE] Linux 2.6 Real Time Kernel |
| |
On Fri, Oct 15, 2004 at 05:45:42PM +0200, Ingo Molnar wrote: > > * Paul E. McKenney <paulmck@us.ibm.com> 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?
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/
| |