| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Only use `clone3` when needed for pidfd
In #89522 we learned that `clone3` is interacting poorly with Gentoo's
`sandbox` tool. We only need that for the unstable pidfd extensions, so
otherwise avoid that and use a normal `fork`.
This is a re-application of beta #89924, now that we're aware that we need
more than just a temporary release fix. I also reverted 12fbabd27f700, as
that was just fallout from using `clone3` instead of `fork`.
r? `@Mark-Simulacrum`
cc `@joshtriplett`
|
|
|
|
This reverts commit 12fbabd27f700a59d0e7031f0839b220c3514bcb.
It was only needed because of using raw `clone3` instead of `fork`, but
we only do that now when a pidfd is requested.
|
|
The test calls libc::getpid() in the pre_exec hook and asserts that the returned value is different from the PID of the parent.
However, libc::getpid() returns the wrong value.
Before version 2.25, glibc caches the PID of the current process with the goal of avoiding additional syscalls.
The cached value is only updated when the wrapper functions for fork or clone are called.
In PR #81825 we switch to directly using the clone3 syscall.
Thus, the cache is not updated and getpid returns the PID of the parent.
source: https://man7.org/linux/man-pages/man2/getpid.2.html#NOTES
|
|
And link to the issue.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort!
See eg
https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765
This is probably a bug, but we don't want to entangle this MR with it.
When it's fixed, this commit should be reverted.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort!
See eg
https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765
This is probably a bug, but (i) we want to avoid that bug rather than
trying to fix it now and (ii) it would better to use a signal that is
less at risk of strangeness.
I grepped the rust-lang/rut codebase for SIGUSR and there were no hits.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
This tests that we can indeed safely panic after fork, both
a raw libc::fork and in a Command pre_exec hook.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
|
|
|
|
|
|
|
|
ignore process-envs.rs and process-remove-from-env.rs as there is no 'env' on vxWorks
|
|
ignore wait-forked-but-failed-child.rs as there is no command 'ps' on vxWorks
ignore process-sigpipe.rs as there is no 'sh' on vxWorks
ignore core-run-destroy.rs as there is no 'cat' and 'sleep' on vxWorks
|
|
|
