Not competent to review the source code, but other than that disambiguation request, the manual page change LGTM.

FWIW, I tried the tests for your process_sandbox (with this patch applied of course) and one test consistently fails:

markj@biggie> ./test-onebitsem-child
{unknown file}:0 in {unknown function}: Test timed out

Abort trap (core dumped)
...
(gdb) bt                                                                               
#0  thr_kill () at thr_kill.S:4                                                        
#1  0x00000008004a8cf4 in __raise (s=s@entry=6) at /root/freebsd/lib/libc/gen/raise.c:52
#2  0x000000080055a3c9 in abort () at /root/freebsd/lib/libc/stdlib/abort.c:67                                                                                                
#3  0x000000000020a1a9 in snmalloc::PALPOSIX<snmalloc::PALFreeBSD>::error(char const*) ()
#4  0x00000000002112a4 in void sandbox::invariant_fail<test_sem<sandbox::platform::UMtxOneBitSem>()::{lambda()#2}::operator()() const::FMT_COMPILE_STRING>(test_sem<sandbox::p
latform::UMtxOneBitSem>()::{lambda()#2}::operator()() const::FMT_COMPILE_STRING, fmt::v8::basic_format_args<fmt::v8::basic_format_context<fmt::v8::appender, char> >, sandbox:
:source_location) ()                                                                                                                                                          
#5  0x0000000000209248 in void test_sem<sandbox::platform::UMtxOneBitSem>() ()         
#6  0x0000000000208ff9 in main ()

In D33248#752692, @markj wrote:

FWIW, I tried the tests for your process_sandbox (with this patch applied of course) and one test consistently fails:

markj@biggie> ./test-onebitsem-child

This test doesn't touch any of the new code (test-sandbox-fake-open does). Could you take a look at: https://github.com/microsoft/verona/blob/master/experiments/process_sandbox/include/process_sandbox/platform/onebitsem_umtx.h

The test is a unit test that's failing is a unit test for this code and fails intermittently for me (more often on 14 than 12, where it fails very rarely). The equivalent Linux code is here: https://github.com/microsoft/verona/blob/master/experiments/process_sandbox/include/process_sandbox/platform/onebitsem_futex.h

The Linux code never fails for me on Ubuntu. From this I deduce one of the following is true:

• My use of _umtx_op is incorrect.
• There is a bug in the implementation of _umtx_op.
• There is a bug in the test.

The first seems very likely, the second seems moderately likely. The third seems less likely since it passes on Linux (though there is some difference between how the child processes are created - on Linux it will be called in a vfork context, on FreeBSD it's in a pdfork child by default, though if you toggle ENABLE_PROCDESC in ccmake then it will also use vfork on FreeBSD).

Other than that comma splice, both manual page changes (signal.3 and procctl.2) LGTM now.

In D33248#752778, @theraven wrote:

The test is a unit test that's failing is a unit test for this code and fails intermittently for me (more often on 14 than 12, where it fails very rarely). The equivalent Linux code is here: https://github.com/microsoft/verona/blob/master/experiments/process_sandbox/include/process_sandbox/platform/onebitsem_futex.h

The Linux code never fails for me on Ubuntu. From this I deduce one of the following is true:

• My use of _umtx_op is incorrect.
• There is a bug in the implementation of _umtx_op.
• There is a bug in the test.

None of the above. :)

It's a bug in the libc build which results in pdfork() not being interposed by libthr, so various internal locks do not get reinitialized resulting in various deadlocks when the child tries to exit. Fixed by commit cbdec8db18b5 .

Manual page part LGTM now, grammar-wise.

Are there any other blockers to committing this? @markj, please can you approve if not?

In D33248#763988, @theraven wrote:

Are there any other blockers to committing this? @markj, please can you approve if not?

No, just a couple of minor comments. Consider the diff approved.

I missed that @kib was not on the review, I think he should get some time to take a look. There is PR 259778 for context.

Don't you want to have core dumped for unhandled SIGCAP?

In D33248#764167, @kib wrote:

Don't you want to have core dumped for unhandled SIGCAP?

I don't have strong opinions here. I can imagine setting this in a process and inheriting it from a parent process in something that doesn't set up a signal handler and expects to properly handle ENOTCAPABLE returns. Clearing it there is probably a bug, so dumping core is probably the right thing to do, though rtld will crash currently if it runs with this flag inherited, so I can see arguments either way.

I've rebased this, addressed reviewer comments (except the one that wants me to change some whitespace in a way that I don't fully understand), and tested it again with the Verona process-sandbox code.