[PATCH v2 01/15] linux: Add pidfd_open
Matheus Castanho
msc@linux.ibm.com
Wed Jun 1 20:53:11 GMT 2022
Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> On 01/06/2022 15:02, Matheus Castanho wrote:
>>
>> Hi Adhemerval,
>>
>> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
>>
>>> This was added on Linux 5.3 (32fcb426ec001cb6d5a4a195091a8486ea77e2df)
>>> as a way to retrieve a pid file descriptors for process that has not
>>> been created CLONE_PIDFD (by usual fork/clone).
>>> ---
>> [...]
>>> create mode 100644 sysdeps/unix/sysv/linux/tst-pidfd-consts.py
>>
>> This new test fails on systems with older kernels (e.g. Debian 10 -
>> kernel 4.19). Looks like linux/pidfd.h is not available on such systems,
>> so list_macros fails when trying to compile source_2.
>>
>> FAIL: misc/tst-pidfd-consts
>> original exit status 1
>> /tmp/tmp5g72cxka/test.c:2:10: fatal error: linux/pidfd.h: No such file or directory
>> #include <linux/pidfd.h>
>> ^~~~~~~~~~~~~~~
>> compilation terminated.
>
> Not sure how to properly handle it, maybe in this case return UNSUPPORTED:
>
> diff --git a/sysdeps/unix/sysv/linux/tst-pidfd-consts.py b/sysdeps/unix/sysv/linux/tst-pidfd-consts.py
> index 75df0ebed5..cfc9fbc7cb 100644
> --- a/sysdeps/unix/sysv/linux/tst-pidfd-consts.py
> +++ b/sysdeps/unix/sysv/linux/tst-pidfd-consts.py
> @@ -19,6 +19,7 @@
>
> import argparse
> import sys
> +import subprocess
>
> import glibcextract
> import glibcsyscalls
> @@ -35,7 +36,8 @@ def main():
>
> linux_version_headers = glibcsyscalls.linux_kernel_version(args.cc)
> linux_version_glibc = (5, 18)
> - sys.exit(glibcextract.compare_macro_consts(
> + try:
> + sys.exit(glibcextract.compare_macro_consts(
> '#include <sys/pidfd.h>\n',
> '#include <asm/fcntl.h>\n'
> '#include <linux/pidfd.h>\n',
> @@ -44,6 +46,8 @@ def main():
> None,
> linux_version_glibc > linux_version_headers,
> linux_version_headers > linux_version_glibc))
> + except subprocess.CalledProcessError:
> + sys.exit(77)
>
> if __name__ == '__main__':
> main()
I don't think there's much else to do besides returning UNSUPPORTED. Of
course this will mark the test as UNSUPPORTED for any failure in the
internal gcc call, but I don't see it as a problem today since this
function seems to be used only for macro processing.
Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
Tested-by: Matheus Castanho <msc@linux.ibm.com>
Thanks!
Matheus Castanho
More information about the Libc-alpha
mailing list