Re: sysctl_doeproc() race
On 11.03.2018 19:20, Kamil Rytarowski wrote: > On 11.03.2018 18:23, Robert Elz wrote: >> Date:Sun, 11 Mar 2018 16:02:57 +0100 >> From:Kamil Rytarowski >> Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> >> >> | We already use markers so I prefer to stick to this solution and it >> | makes this code reliable. >> >> Actually, since I sent the previous message, I have been thinking on it >> more, and I don't think that it does. >> >> It handles the case where we have found a process on allproc, and it is >> (while we are scanning more of allproc) moved to zombproc, so we won't >> get the process twice. >> > > That was the original design. > > I will have a look at the approach with iterating over pid_table[]. > The approach with iterating over pid_table[] didn't work well for me and I've abandoned it quickly. I've been testing a patch splitting KERN_PROC_PID out into a new branch/function: http://netbsd.org/~kamil/patch-00046-zombielist-marker-sysctl_doeproc-split.txt My impression is that these changes make the code much less readable, and the performance gain was negligible or even negative (!) in a regular running systems with 20-30 processes. I expect that such interface is clearly not a quick-path. I was testing the proposal by Christos swapping zombie and allproc lists and I've found that this code is stable for the original problem. http://netbsd.org/~kamil/patch-00046-zombielist-marker-sysctl_doeproc-swap.txt I've included in this patch additionally: - Short-circuit break for KERN_PROC_PID. - Removal of redundant "if (kbuf)" and "if (marker)" checks. - Update of comments regarding potential optimization, explaining why we don't want it. - ESRCH returned for badly written software, that is not prepared to see no result (or see race). This also makes the case of replying a call easier to detect. I've not observed any ATF regression in local tests and I'm going to commit this code swapping allproc and zombieproc order of checking now. signature.asc Description: OpenPGP digital signature
Re: gcc spectre stuff for netbsd-8
Additionally, why skipping -current entirely: - GCC 7.3 already has an official backport, and we might update to this. - I'm not good at compilers p.s. for people who desperately want -current patches, we can still use GCC 5.5 on current with HAVE_GCC=5.
Re: gcc spectre stuff for netbsd-8
sorry for being terse, I'm not very knowledgeable about GCC/x86 but applied it to our copy of GCC. what it should be adding Add -mindirect-branch-register to force indirect branch via register. This is implemented by disabling patterns of indirect branch via memory, similar to TARGET_X32. https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00427.html Add -mindirect-branch= option to convert indirect call and jump to call and return thunks. The default is 'keep', which keeps indirect call and jump unmodified. 'thunk' converts indirect call and jump to call and return thunk. 'thunk-inline' converts indirect call and jump to inlined call and return thunk. 'thunk-extern' converts indirect call and jump to external call and return thunk provided in a separate object file. You can control this behavior for a specific function by using the function attribute indirect_branch. https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00424.html Add -mfunction-return= option to convert function return to call and return thunks. The default is 'keep', which keeps function return unmodified. 'thunk' converts function return to call and return thunk. 'thunk-inline' converts function return to inlined call and return thunk. 'thunk-extern' converts function return to external call and return thunk provided in a separate object file. You can control this behavior for a specific function by using the function attribute function_return. https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00426.html
gcc spectre stuff for netbsd-8
Hi, I've done the following, hopefully it will enable others. Completed: - Builds amd64 tools - Builds working amd64 kernel (*without new mitigations*!) Need: - Test full release, stress test - Test i386 too - Decide which spectre mitigation to use - Test that kernel with that mitigation works - Also, modules! - Run the new testcases from GCC testsuite which were added with this feature Maybe: - Figure out what I just did to the documentation? Patch: http://netbsd.org/~maya/netbsd8-gcc-spectre-20180312 (Originally from opensuse's gcc patch, and comparing a lot to gcc-HEAD where it was insufficient)
