The variable is written in the child process which shares the address
space with the parent. The data flow must not be optimized by a compiler.
Fixes: ddf62c83fc0a ("sys/tests/kern/pdopenpid: pdopenpid(2) is allowed in cap mode")Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
I believe that volatile matches the issue I need to prevent, while atomic is not.
There is no race involved there, the accesses are serialized by the residual _exit() call in the child vs. the wait for P_PPWAIT condition to resume of the execution in the parent.
So the problem is that the grandchild variable could be modified in the way that cannot be deduced from the flow control visible to the compiler, and not a race.
The C23 standard explicitly describes the situation as the subject of the volatile semantic:
An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore, any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.4. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.150) What constitutes an access to an object that has volatile-qualified type is implementation-defined.