lkml.org 
[lkml]   [2004]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:1.305 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site