Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2

["Paul E. McKenney" <paulmck@us.ibm.com>]

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