NetBSD-Bugs archive

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

kern/38947: minor race for signals with multithreaded process

>Number:         38947
>Category:       kern
>Synopsis:       minor race for signals with multithreaded process
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 12 15:15:00 +0000 2008
>Originator:     Andrew Doran
>Release:        4.99.64
The NetBSD Project
Seems like a bad thing to do, but I don't know if it really is a problem:

A process has two threads.

A signal arrives for the process and neither thread has it masked.

Both threads notice the signal pending in sleepq_block(), and return EINTR 
The two threads then race to get to userret() on the kernel/user boundary,
where the signal will be dispatched.

Only one thread can dequeue and process the signal, but both will return
an error.

Code inspection.

Maybe have the issignal() in sleepq_block() dequeue the signal from the 
process pending list and enqueue it to the per-thread pending list if
it's known that the signal can be handled. We would need to handle cases
where the thread doesn't get to the kernel/user boundary which would be

Home | Main Index | Thread Index | Old Index