Re: [PATCH] de_thread: eliminate unneccessary sighand locking

[Ingo Molnar <mingo@elte.hu>]

* Roland McGrath <roland@redhat.com> wrote:

> > the amount of potentially affected code (assuming all the locking is 
> > done in a single .[ch] file)
> 
> I'm not sure what that means.  I'm not confident that all relevant 
> locking code is always in one file.  If you mean that you did as I 
> said, checked every use of siglock and confirmed that tasklist_lock is 
> held before examining ->sighand, then we are good.

no, i didnt check all of that. I only checked the obvious places where 
all 3 methods are used in a single module.

> > this reminds me about the patch below: it gets rid of tasklist_lock use 
> > in the POSIX timer signal delivery critical path.
> 
> I don't see how that works at all.  The thought that it would seems to 
> contradict what we've just been discussing.  Holding tasklist_lock is 
> what protects against ->sighand and ->signal changing and the old 
> pointers becoming stale, not task_lock.  What am I missing here?

yeah, it's a bad patch. Offtopic, but it's a real problem: the signal 
code is inevitably holding the tasklist_lock for long times when sending 
group signals, which is interfering with the signal-sending ability of 
upcoming features like high-resolution timers (which uses 
send_sigqueue()).

Could we get rid of tasklist_lock and do a careful lock-step walking of 
the thread hierarchy (locking the next thread, unlocking the previous 
thread in every step), or are there signal semantics reasons for doing 
it all in one atomic step?

	Ingo