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 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.



    \
     
     \ /
      Last update: 2009-12-10 15:43    [W:0.029 / U:1.172 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site