Fix getpid errno assertions in multi_thread test#96
Fix getpid errno assertions in multi_thread test#96petreeftime merged 1 commit intorust-vmm:mainfrom
Conversation
rschmitt
changed the title
rschmitt
force-pushed
the
main
branch
3 times, most recently
from
1896dc3 to
d2958a8
Compare
| let pid = unsafe { libc::getpid() }; | ||
| // Clear any stale `errno` value | ||
| unsafe { *libc::__errno_location() = 0; } | ||
| // Go through the generic `syscall` function, as `getpid` does not set `errno` |
There was a problem hiding this comment.
I don't think that's strictly true, but I think that glibc might do caching, so it won't always call the syscall, which is what we want in this case.
There was a problem hiding this comment.
I don't think that's strictly true
It's trivially true for musl: kraj/musl@d878dce
glibc is weirder because the implementations of functions like getpid are all generated, but this blog post explains the syscall wrapper generation and mentions getpid specifically:
There are three kind of system call which is defined by ‘T_PSEUDO’, ‘T_PSEUDO_NOERRNO’ and ‘T_PSEUDO_ERRVAL’. If ‘SYSCALL_NOERRNO’ is defined then the system call is wrapped by ‘T_PSEUDO_NOERRNO’, this means the wrapper doesn’t return error code, for example the ‘getpid’ and ‘umask’ system call.
The args for getpid are defined in glibc here as Ei:, and E indicates that errno is not set by the call.
I think that glibc might do caching
Not since glibc 2.25 (2017-02-05): https://sourceware.org/glibc/wiki/Release/2.25#Calls_to_getpid_are_no_longer_cached
|
Can you please use cargo fmt? This test is failing: https://buildkite.com/rust-vmm/seccompiler-ci/builds/209/steps/canvas?sid=019c9684-b38e-40f7-b5bc-37696a063a07. |
There are two issues with this test. 1. On my Linux 5.10 machine, `errno` is set to `ENOENT` as soon as the test begins. Somehow the Rust test harness is making a syscall that is failing, and that stale value is getting read from `errno` and causing the assertion failure early in `test_tsync`. This is fixed by simply clearing `errno` before calling `getpid`. 2. `getpid()` from libc does not set `errno` on either glibc or musl, hence the strange `errno == 0` assertion after making a `getpid` call that failed. This is fixed by doing through the generic `syscall()` function, which _does_ set `errno` so that we can compare it to the expected `EPERM`. Signed-off-by: Ryan Schmitt <rschmitt@pobox.com>
2 participants
There are two issues with this test.
errnois set toENOENTas soon as the test begins. Somehow the Rust test harness is making a syscall that is failing, and that stale value is getting read fromerrnoand causing the assertion failure early intest_tsync. This is fixed by simply clearingerrnobefore callinggetpid.getpid()from libc does not seterrnoon either glibc or musl, hence the strangeerrno == 0assertion after making agetpidcall that failed. This is fixed by going through the genericsyscall()function, which does seterrnoso that we can compare it to the expectedEPERM.