Messages in this thread |  | | Date | Sun, 16 Feb 2003 21:23:21 +0100 | From | Manfred Spraul <> | Subject | Re: more signal locking bugs? |
| |
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/
|  |