AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-11-23 13:30:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
bad554d9b4
glibc/stdlib/tst-concurrent-exit.c

23 lines
959 B
C
Raw Normal View History

stdlib: Allow concurrent exit (BZ 31997) Even if C/POSIX standard states that exit is not formally thread-unsafe, calling it more than once is UB. The glibc already supports it for the single-thread, and both elf/nodelete2.c and tst-rseq-disable.c call exit from a DSO destructor (which is called by _dl_fini, registered at program startup with __cxa_atexit). However, there are still race issues when it is called more than once concurrently by multiple threads. A recent Rust PR triggered this issue [1], which resulted in an Austin Group ask for clarification [2]. Besides it, there is a discussion to make concurrent calling not UB [3], wtih a defined semantic where any remaining callers block until the first call to exit has finished (reentrant calls, leaving through longjmp, and exceptions are still undefined). For glibc, at least reentrant calls are required to be supported to avoid changing the current behaviour. This requires locking using a recursive lock, where any exit called by atexit() handlers resumes at the point of the current handler (thus avoiding calling the current handle multiple times). Checked on x86_64-linux-gnu and aarch64-linux-gnu. [1] https://github.com/rust-lang/rust/issues/126600 [2] https://austingroupbugs.net/view.php?id=1845 [3] https://www.openwall.com/lists/libc-coord/2024/07/24/4 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2024-07-25 18:41:44 +00:00
/* Check if exit can be called concurrently by multiple threads.
Copyright (C) 2024 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<https://www.gnu.org/licenses/>. */
stdlib: Allow concurrent quick_exit (BZ 31997) As for exit, also allows concurrent quick_exit to avoid race conditions when it is called concurrently. Since it uses the same internal function as exit, the __exit_lock lock is moved to __run_exit_handlers. It also solved a potential concurrent when calling exit and quick_exit concurrently. The test case 'expected' is expanded to a value larger than the minimum required by C/POSIX (32 entries) so at_quick_exit() will require libc to allocate a new block. This makes the test mre likely to trigger concurrent issues (through free() at __run_exit_handlers) if quick_exit() interacts with the at_quick_exit list concurrently. This is also the latest interpretation of the Austin Ticket [1]. Checked on x86_64-linux-gnu. [1] https://austingroupbugs.net/view.php?id=1845 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2024-08-05 14:27:35 +00:00
#define EXIT(__r) exit (__r)
#define ATEXIT(__f) atexit (__f)
stdlib: Allow concurrent exit (BZ 31997) Even if C/POSIX standard states that exit is not formally thread-unsafe, calling it more than once is UB. The glibc already supports it for the single-thread, and both elf/nodelete2.c and tst-rseq-disable.c call exit from a DSO destructor (which is called by _dl_fini, registered at program startup with __cxa_atexit). However, there are still race issues when it is called more than once concurrently by multiple threads. A recent Rust PR triggered this issue [1], which resulted in an Austin Group ask for clarification [2]. Besides it, there is a discussion to make concurrent calling not UB [3], wtih a defined semantic where any remaining callers block until the first call to exit has finished (reentrant calls, leaving through longjmp, and exceptions are still undefined). For glibc, at least reentrant calls are required to be supported to avoid changing the current behaviour. This requires locking using a recursive lock, where any exit called by atexit() handlers resumes at the point of the current handler (thus avoiding calling the current handle multiple times). Checked on x86_64-linux-gnu and aarch64-linux-gnu. [1] https://github.com/rust-lang/rust/issues/126600 [2] https://austingroupbugs.net/view.php?id=1845 [3] https://www.openwall.com/lists/libc-coord/2024/07/24/4 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2024-07-25 18:41:44 +00:00
stdlib: Allow concurrent quick_exit (BZ 31997) As for exit, also allows concurrent quick_exit to avoid race conditions when it is called concurrently. Since it uses the same internal function as exit, the __exit_lock lock is moved to __run_exit_handlers. It also solved a potential concurrent when calling exit and quick_exit concurrently. The test case 'expected' is expanded to a value larger than the minimum required by C/POSIX (32 entries) so at_quick_exit() will require libc to allocate a new block. This makes the test mre likely to trigger concurrent issues (through free() at __run_exit_handlers) if quick_exit() interacts with the at_quick_exit list concurrently. This is also the latest interpretation of the Austin Ticket [1]. Checked on x86_64-linux-gnu. [1] https://austingroupbugs.net/view.php?id=1845 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2024-08-05 14:27:35 +00:00
#include "tst-concurrent-exit-skeleton.c"
Reference in New Issue Copy Permalink