Messages in this thread | | | Date | Sat, 23 Oct 2004 14:12:28 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 |
| |
On Sat, Oct 23, 2004 at 10:24:51PM +0200, Ingo Molnar wrote: > * Paul E. McKenney <paulmck@us.ibm.com> wrote: > > o The rcu_read_lock_spin(), rcu_read_lock_read(), > > rcu_read_lock_bh_read(), rcu_read_lock_sem(), and > > rcu_read_lock_bh_spin() APIs cannot be called recursively. > > But you probably already knew that. ;-) > > > > I don't understand why the rcu_read_lock_sem() API gets its > > own #ifdef. > > actually, rcu_read_lock_read() is the variant that _can_ be called > recursively and which i used in the networking code quite extensively. > The others are only useful if the locking is 'flat' in the original > code, or if the locking is extensively rewritten. (I havent tried to > convert the IPC code back from the 'flat' locking to the original > 'nested' locking, but i've done it for the networking code.)
OK, sorry for my confusion. I still don't see why rcu_read_lock_sem() is segregated, but it will clearly work either way.
> > o Some recent RCU patches acquire the update-side lock > > under rcu_read_lock(), which I believe will deadlock here. > > which codepaths do you mean? Things are looking pretty good in -U10.3 so > far.
The one that I am aware of has not yet hit mainline -- Kaigai Kohei's scalability changes to Linux. See:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109628285418353&w=2
The function avc_update_cache() does an rcu_read_lock(), then invokes avc_update_node(), which acquires the update-side lock. No problem under conventional RCU, in the case where one might realize that an update is needed during what is a read-only search in the common case, but would be problematic given real-time preemption.
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/
| |