From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1791) id 488F9399C8B4; Wed, 9 Jun 2021 18:17:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 488F9399C8B4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Adhemerval Zanella To: glibc-cvs@sourceware.org Subject: [glibc] nptl: Avoid async cancellation to wrongly update __nptl_nthreads (BZ #19366) X-Act-Checkin: glibc X-Git-Author: Adhemerval Zanella X-Git-Refname: refs/heads/master X-Git-Oldrev: a6c813d0ad0fd9830f2cd3c3d079af8d2aa50a1f X-Git-Newrev: 8fe503f74e0a2ab41eec9bbae1e0ea8f5203716b Message-Id: <20210609181736.488F9399C8B4@sourceware.org> Date: Wed, 9 Jun 2021 18:17:36 +0000 (GMT) X-BeenThere: glibc-cvs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 18:17:36 -0000 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8fe503f74e0a2ab41eec9bbae1e0ea8f5203716b commit 8fe503f74e0a2ab41eec9bbae1e0ea8f5203716b Author: Adhemerval Zanella Date: Thu May 27 12:42:13 2021 -0300 nptl: Avoid async cancellation to wrongly update __nptl_nthreads (BZ #19366) The testcase provided on BZ#19366 may update __nptl_nthreads in a wrong order, triggering an early process exit because the thread decrement the value twice. The issue is once the thread exits without acting on cancellation, it decreaments '__nptl_nthreads' and then atomically set 'cancelhandling' with EXITING_BIT (thus preventing further cancellation handler to act). The issue happens if a SIGCANCEL is received between checking '__ntpl_nthreads' and setting EXITING_BIT. To avoid it, the '__nptl_nthreads' decrement is moved after EXITING_BIT. It does fully follow the POSIX XSH 2.9.5 Thread Cancellation under the heading Thread Cancellation Cleanup Handlers that states that when a cancellation request is acted upon, or when a thread calls pthread_exit(), the thread first disables cancellation by setting its cancelability state to PTHREAD_CANCEL_DISABLE and its cancelability type to PTHREAD_CANCEL_DEFERRED. The issue is '__pthread_enable_asynccancel' explicit enabled assynchrnous cancellation, so an interrupted syscall within the cancellation cleanup handlers might see an invalid cancelling type (a possible fix might be possible with my proposed solution to BZ#12683). Trying to come up with a test is quite hard since it requires to mimic the timing issue described below, however I see that the bug report reproducer does not early exit anymore. Checked on x86_64-linux-gnu. Diff: --- nptl/pthread_create.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c index 72ecda8b63..3f017f1e26 100644 --- a/nptl/pthread_create.c +++ b/nptl/pthread_create.c @@ -439,13 +439,6 @@ start_thread (void *arg) /* Clean up any state libc stored in thread-local variables. */ __libc_thread_freeres (); - /* If this is the last thread we terminate the process now. We - do not notify the debugger, it might just irritate it if there - is no thread left. */ - if (__glibc_unlikely (atomic_decrement_and_test (&__nptl_nthreads))) - /* This was the last thread. */ - exit (0); - /* Report the death of the thread if this is wanted. */ if (__glibc_unlikely (pd->report_events)) { @@ -480,6 +473,10 @@ start_thread (void *arg) the breakpoint reports TD_THR_RUN state rather than TD_THR_ZOMBIE. */ atomic_bit_set (&pd->cancelhandling, EXITING_BIT); + if (__glibc_unlikely (atomic_decrement_and_test (&__nptl_nthreads))) + /* This was the last thread. */ + exit (0); + #ifndef __ASSUME_SET_ROBUST_LIST /* If this thread has any robust mutexes locked, handle them now. */ # if __PTHREAD_MUTEX_HAVE_PREV