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.024 / U:152.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site