| Date | Thu, 10 Dec 2009 15:45:28 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 7/9] signals: Fix more rcu assumptions |
| |
On Thu, 10 Dec 2009, Oleg Nesterov wrote:
> 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.
Indeed. Was too tired to see the obvious :)
Thanks,
tglx
|