Messages in this thread | | | Date | Sat, 23 Oct 2004 22:24:51 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 |
| |
* Paul E. McKenney <paulmck@us.ibm.com> wrote:
> o In rcupdate.h, I believe that the: > > +# define rcu_read_unlock_nort() rcu_read_lock_nort() > > should instead be: > > +# define rcu_read_unlock_nort() rcu_read_unlock()
yeah, correct - fortunately this is a non-default path, but still a nice fix.
> 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.)
> 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.
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/
| |