Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Matthew Dempsky
On Tue, Jul 8, 2014 at 3:51 PM, Philip Guenther wrote: > * using atomics when we don't even have correct process-pending signals > risks a solution that >doesn't work when more than one pending set has to be examined. I'll hold off on this until we have process-pending signals then.

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Philip Guenther
On Mon, Jul 7, 2014 at 1:46 PM, Matthew Dempsky wrote: > p_sigmask is only modified by the owning thread from process context > (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()), > but it can be accessed anywhere (e.g., interrupts or threads on other > CPUs). Currently sys_sigp

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Matthew Dempsky
Updated diff below with the following changes: - p_sigmask is now volatile, per kettenis's request - kern_fork.c's memcpy() for p_startcopy needs to cast away the volatile now - kettenis pointed out atomic_swap_uint() isn't safe to use in MI code yet, so for now proc_sigsetmask() just relies o

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Mark Kettenis
> Date: Tue, 8 Jul 2014 09:05:38 -0700 > From: Matthew Dempsky > > On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis wrote: > >> Date: Mon, 7 Jul 2014 13:46:03 -0700 > >> From: Matthew Dempsky > >> > >> p_sigmask is only modified by the owning thread from process context > >> (e.g., sys_sigprocmask

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Matthew Dempsky
On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis wrote: >> Date: Mon, 7 Jul 2014 13:46:03 -0700 >> From: Matthew Dempsky >> >> p_sigmask is only modified by the owning thread from process context >> (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()), >> but it can be accessed anywhe

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Matthew Dempsky
On Tue, Jul 8, 2014 at 1:21 AM, Martin Pieuchot 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

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Mark Kettenis
> Date: Mon, 7 Jul 2014 13:46:03 -0700 > From: Matthew Dempsky > > p_sigmask is only modified by the owning thread from process context > (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()), > but it can be accessed anywhere (e.g., interrupts or threads on other > CPUs). Currentl

Re: Use atomics for mutating p_sigmask

2014-07-08 Thread Martin Pieuchot
On 07/07/14(Mon) 13:46, Matthew Dempsky wrote: > p_sigmask is only modified by the owning thread from process context > (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()), > but it can be accessed anywhere (e.g., interrupts or threads on other > CPUs). Currently sys_sigprocmask()

Use atomics for mutating p_sigmask

2014-07-07 Thread Matthew Dempsky
p_sigmask is only modified by the owning thread from process context (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()), but it can be accessed anywhere (e.g., interrupts or threads on other CPUs). Currently sys_sigprocmask() protects p_sigmask with splhigh(), but that's not MP-sa