| | Date | Thu, 10 Dec 2009 15:34:35 +0100 | | From | Oleg Nesterov <> | | Subject | Re: [patch 7/9] signals: Fix more rcu assumptions |
| |
On 12/10, Thomas Gleixner wrote: > > 1) Remove the misleading comment in __sigqueue_alloc() which claims > that holding a spinlock is equivalent to rcu_read_lock(). > > 2) Wrap the __send_signal() call in send_signal() into a rcu read side > critical section to guarantee that the __sigqueue_alloc() > requirement is met in any case. > ... > static int send_signal(int sig, struct siginfo *info, struct task_struct *t, > int group) > { > - int from_ancestor_ns = 0; > + int ret, from_ancestor_ns = 0; > > #ifdef CONFIG_PID_NS > if (!is_si_special(info) && SI_FROMUSER(info) && > @@ -954,7 +953,11 @@ static int send_signal(int sig, struct s > from_ancestor_ns = 1; > #endif > > - return __send_signal(sig, info, t, group, from_ancestor_ns); > + rcu_read_lock(); > + ret = __send_signal(sig, info, t, group, from_ancestor_ns); > + rcu_read_unlock();
But, without a comment it is very unobvious why do we need rcu_read_lock().
Perhaps it is better to modify __sigqueue_alloc() instead? It can take rcu_lock() around cred->user itself.
Oleg.
|