On Tue, Jul 8, 2014 at 1:21 AM, Martin Pieuchot <mpieuc...@nolizard.org> wrote: > There was a previous attempt to mark sigpromask(2) as nolock but if I > recall properly setting p_sigmask atomically is not enough and there's > still a possible race in ptsignal(). > > Have you looked into this function, is it safe now?
I haven't looked very closely yet, but I'll be sure to look again before proposing NOLOCK for sys_sigprocmask(). However, this diff only replaces the SPLs with atomic operations; it leaves sys_sigprocmask() under kernel lock. As long as sys_sigprocmask() is still kernel locked, ptsignal() can only execute concurrently with sys_sigprocmask() if its an interrupt on the same CPU. Without this diff, that interrupt can only occur before or after the SPL-protected code section; while after this diff, the interrupt can only occur before or after the atomic operation (since by definition atomic operations are atomic).
