>> Date: Thu, 7 Apr 2016 13:10:23 +0200 >> From: Michal Mazurek <[email protected]> >> >> Depending on the NOLOCK flag, the KERNEL_LOCK will, or will not be acquired >> before calling pledge_syscall(). I therefore conclude that KERNEL_LOCK >> is not needed to call pledge_syscall(). > >It really depends on what the behaviour of pledge(2) is supposed to be >in multi-threaded processes. Since pledge(2) itself isn't a NOLOCK >system call, the current code guarantees that all other system calls >that aren't marked as NOLOCK, have a consitent view of the >pledge-related state, at least as long as they don't sleep. With your >change those system calls will enounter the same race as NOLOCK system >calls. And these system calls are more likely to suffer from >side-effects as they tend to be more complex. > >This is not necessarily a big issue. But we need to be careful about >the checks we do. As long as we keep the upfront checks simple, the >risks are low. But people pledging should be aware that there are >races in multi-threaded code and that they really should call >pledge(2) before creating threads.
Yes. I wrote it the way it is, because I am terrified of getting it wrong. I am very unsure that the provided diff makes the right gaurantees of interlock between threads. Imagine one thread performing the pledge, while another thread is merrily advancing doing NOLOCK system calls (I cannot be certain that is wrong, but the weak semantics feel wrong).
