about summary refs log tree commit diff
path: root/sysdeps/unix/sysv/linux/wait4.c
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-011-1/+1
|
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-061-1/+1
|
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
* Update copyright dates with scripts/update-copyrightsPaul Eggert2021-01-021-1/+1
| | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 6694 files FOO. I then removed trailing white space from benchtests/bench-pthread-locks.c and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this diagnostic from Savannah: remote: *** pre-commit check failed ... remote: *** error: lines with trailing whitespace found remote: error: hook declined to update refs/heads/master
* linux: wait4: Fix incorrect return value comparisonAlistair Francis2020-04-141-10/+9
| | | | | | | | | | Patch 600f00b "linux: Use long time_t for wait4/getrusage" introduced two bugs: - The usage32 struct was set if the wait4 syscall had an error. - For 32-bit systems the usage struct was set even if it was specified as NULL. This patch fixes the two issues.
* linux: Use long time_t for wait4/getrusageAlistair Francis2020-04-021-2/+48
| | | | | | | | | | | | | | The Linux kernel expects rusage to use a 32-bit time_t, even on archs with a 64-bit time_t (like RV32). To address this let's convert rusage to/from 32-bit and 64-bit to ensure the kernel always gets a 32-bit time_t. While we are converting these functions let's also convert them to be the y2038 safe versions. This means there is a *64 function that is called by a backwards compatible wrapper. Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update copyright dates with scripts/update-copyrights.Joseph Myers2020-01-011-1/+1
|
* Implement waitpid in terms of wait4Adhemerval Zanella2019-12-191-0/+1
| | | | | | This also consolidate all waitpid implementations. Checked on x86_64-linux-gnu.
* linux: Use waitid on wait4 if __NR_wait4 is not definedAdhemerval Zanella2019-12-191-0/+84
If the wait4 syscall is not available (such as y2038 safe 32-bit systems) waitid should be used instead. However prior Linux 5.4 waitid is not a full superset of other wait syscalls, since it does not include support for waiting for the current process group. It is possible to emulate wait4 by issuing an extra syscall to get the current process group, but it is inherent racy: after the current process group is received and before it is passed to waitid a signal could arrive causing the current process group to change. So waitid is used if wait4 is not defined iff the build is enabled with a minimum kernel if 5.4+. The new assume __ASSUME_WAITID_PID0_P_PGID is added and an error is issued if waitid can not be implemented by either __NR_wait4 or __NR_waitid && __ASSUME_WAITID_PID0_P_PGID. Checked on x86_64-linux-gnu and i686-linux-gnu. Co-authored-by: Alistair Francis <alistair.francis@wdc.com>