Re: more signal locking bugs?

From: Manfred Spraul (manfred@colorfullife.com)
Date: Sun Feb 16 2003 - 15:23:21 EST


Linus Torvalds wrote:

>>What about this minimal patch? The performance critical operation is
>>signal delivery - we should fix the synchronization between signal
>>delivery and exec first.
>>
>>
>
>The patch looks ok, although I'd also remove the locking and testing from
>collect_sigign_sigcatch() once it is done at a higher level.
>
>And yeah, what about signal delivery? Put back the same lock there?
>
>
I don't know.
Taking read_lock(&tasklist_lock) for send_specific_sig_info might hurt
scalability. Ingo?

If we do not want a global lock, then we have two options:
- make task_lock an interrupt spinlock.
- add a second spinlock to the task structure, for the signal stuff.

Design question - what's worse? Memory bloat or a few additional
local_irq_{en,dis}able().
I don't care - no performance critical codepaths.
Additionally many task_lock()/task_unlock users could be replaced with
spin_unlock_wait(&task->alloc_lock), which would not need the
local_irq_disable().

--
    Manfred

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



This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:15 EST