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


\
 
 \ /
  Last update: 2009-12-10 15:51    [W:0.290 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site