glibc/sysdeps/pthread, branch master

Add crt1-2.0.o for glibc 2.0 compatibility tests

2024-05-06T14:49:40Z

Starting from glibc 2.1, crt1.o contains _IO_stdin_used which is checked by _IO_check_libio to provide binary compatibility for glibc 2.0. Add crt1-2.0.o for tests against glibc 2.0. Define tests-2.0 for glibc 2.0 compatibility tests. Add and update glibc 2.0 compatibility tests for stderr, matherr and pthread_kill. Reviewed-by: Carlos O'Donell

nptl: Fix tst-cancel30 on kernels without ppoll_time64 support

2024-04-23T19:16:32Z

Fall back to ppoll if ppoll_time64 fails with ENOSYS. Fixes commit 370da8a121c3ba9eeb2f13da15fc0f21f4136b25 ("nptl: Fix tst-cancel30 on sparc64"). Reviewed-by: Adhemerval Zanella

Always define __USE_TIME_BITS64 when 64 bit time_t is used

2024-04-02T18:28:36Z

It was raised on libc-help [1] that some Linux kernel interfaces expect the libc to define __USE_TIME_BITS64 to indicate the time_t size for the kABI. Different than defined by the initial y2038 design document [2], the __USE_TIME_BITS64 is only defined for ABIs that support more than one time_t size (by defining the _TIME_BITS for each module). The 64 bit time_t redirects are now enabled using a different internal define (__USE_TIME64_REDIRECTS). There is no expected change in semantic or code generation. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and arm-linux-gnueabi [1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html [2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Reviewed-by: DJ Delorie

signal: Avoid system signal disposition to interfere with tests

2024-03-27T16:47:09Z

Both tst-sigset2 and tst-signal1 expectes that SIGINT disposition is set to SIG_DFL.

Update copyright dates with scripts/update-copyrights

2024-01-01T18:53:40Z

sysdeps: sem_open: Clear O_CREAT when semaphore file is expected to exist [BZ #30789]

2023-11-03T18:19:38Z

When invoking sem_open with O_CREAT as one of its flags, we'll end up in the second part of sem_open's "if ((oflag & O_CREAT) == 0 || (oflag & O_EXCL) == 0)", which means that we don't expect the semaphore file to exist. In that part, open_flags is initialized as "O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC" and there's an attempt to open(2) the file, which will likely fail because it won't exist. After that first (expected) failure, some cleanup is done and we go back to the label "try_again", which lives in the first part of the aforementioned "if". The problem is that, in that part of the code, we expect the semaphore file to exist, and as such O_CREAT (this time the flag we pass to open(2)) needs to be cleaned from open_flags, otherwise we'll see another failure (this time unexpected) when trying to open the file, which will lead the call to sem_open to fail as well. This can cause very strange bugs, especially with OpenMPI, which makes extensive use of semaphores. Fix the bug by simplifying the logic when choosing open(2) flags and making sure O_CREAT is not set when the semaphore file is expected to exist. A regression test for this issue would require a complex and cpu time consuming logic, since to trigger the wrong code path is not straightforward due the racy condition. There is a somewhat reliable reproducer in the bug, but it requires using OpenMPI. This resolves BZ #30789. See also: https://bugs.launchpad.net/ubuntu/+source/h5py/+bug/2031912 Signed-off-by: Sergio Durigan Junior Co-Authored-By: Simon Chopin Co-Authored-By: Adhemerval Zanella Netto Fixes: 533deafbdf189f5fbb280c28562dd43ace2f4b0f ("Use O_CLOEXEC in more places (BZ #15722)")

Exclude routines from fortification

2023-07-05T14:59:48Z

Since the _FORTIFY_SOURCE feature uses some routines of Glibc, they need to be excluded from the fortification. On top of that: - some tests explicitly verify that some level of fortification works appropriately, we therefore shouldn't modify the level set for them. - some objects need to be build with optimization disabled, which prevents _FORTIFY_SOURCE to be used for them. Assembler files that implement architecture specific versions of the fortified routines were not excluded from _FORTIFY_SOURCE as there is no C header included that would impact their behavior. Reviewed-by: Siddhesh Poyarekar

tests: replace read by xread

2023-06-19T13:14:56Z

With fortification enabled, read calls return result needs to be checked, has it gets the __wur macro enabled. Note on read call removal from sysdeps/pthread/tst-cancel20.c and sysdeps/pthread/tst-cancel21.c: It is assumed that this second read call was there to overcome the race condition between pipe closure and thread cancellation that could happen in the original code. Since this race condition got fixed by d0e3ffb7a58854248f1d5e737610d50cd0a60f46 the second call seems superfluous. Hence, instead of checking for the return value of read, it looks reasonable to simply remove it. Reviewed-by: Siddhesh Poyarekar

tests: replace fgets by xfgets

2023-06-13T23:59:08Z

With fortification enabled, fgets calls return result needs to be checked, has it gets the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar

pthreads: Use _exit to terminate the tst-stdio1 test

2023-06-06T09:39:06Z

Previously, the exit function was used, but this causes the test to block (until the timeout) once exit is changed to lock stdio streams during flush.