Re: [PATCH] Fixes for RCU handling of task_struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Paul E. McKenney" wrote:
>
> > > -       spin_lock_irqsave(&p->sighand->siglock, flags);
> > > +       spin_lock_irqsave(&sh->siglock, flags);
> >
> > But 'sh' can be NULL, no? Yes, you already checked PF_EXITING, so this is
> > very unlikely, but I think it is still possible in theory. 'sh' was loaded
> > before reading p->flags, but rcu_read_lock() does not imply memory barrier.
>
> 'sh' cannot be NULL, because the caller holds ->it_lock and has checked
> for timer deletion under that lock, and because the exiting process
> quiesces and deletes timers before freeing sighand.
               ^^^^^^^^^^^^^^

Exiting process (thread group) - yes, but exiting thread - no. That is why
send_sigqueue() should check that the target thread is not exiting now. If
we do not take tasklist_lock we can't be sure that ->sighand != NULL. The
caller holds ->it_lock, yes, but this can't help.

Please don't be confused by the 'posix_cpu_timers_exit(tsk)' in __exit_signal()
which is called under sighand->siglock before clearing ->signal/->sighand. This
is completely different, it detaches (but not destroys) cpu-timers, these timers
can have another thread/process as a target for signal sending.

Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux