From patchwork Thu Jul 11 14:07:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 93740 X-Patchwork-Delegate: fweimer@redhat.com Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 70FBE383E50D for ; Thu, 11 Jul 2024 14:07:43 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 370E8384A050 for ; Thu, 11 Jul 2024 14:07:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 370E8384A050 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 370E8384A050 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720706837; cv=none; b=xQegIY3n2ijLFt7Hj0vJggalB4z3koP3jVl0GhxDFnCXAMAFDHIwTtmuPbz7dqcqjmP+opqd6EQYjt+iziCK0htvD4qp6X66oDFyAMOMEImsnC9xHy9DIdeHiyXYJbc0t0L6/rEx7DtzLYy/LBaNR3QRzzscc8Id6m96klCUqh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720706837; c=relaxed/simple; bh=GYlj+G9UasBA4UsNxtCnG5q8ckH2aNv2J+t0L0j663s=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=GtYPuJOLdFGUKV+q+DVwJ0V3ljxWcYx4kYsldqPcUhmOJd4G1oiWKuscaYI+U3hmrGLNGArMvz6fK1bp7uQ64c/FLnBxb9tLPmqX/wqMeqLcQwIa0Cu/B2XhQRhXvVZA8Am9dBd2I48KkhdKRcPmeLdFe5Absjs51fMQcfj8jyg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720706834; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+saMeEp6K8b2UuiArXvx/5umzNSvC8hLDSPiwl4HDHI=; b=KDOXrTxGuF26jbEaUEFf35rZqi9N3r5ofr7jcLVMX7IdVteLi3IRON7R85BLavKoGApn3R 7UBEZ0nbaOTkrJ+B4cOY+mzrf7onKUdX5FznoALv9f7Im9oUJ71bosLATeaJzqLLAFzRJR 53f6rBjJXWeUfcmGFAXsc7qqmHxPcpw= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-350-dwxXe_K0MJam83prgy9L2A-1; Thu, 11 Jul 2024 10:07:13 -0400 X-MC-Unique: dwxXe_K0MJam83prgy9L2A-1 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-a77e024eaa4so95347866b.0 for ; Thu, 11 Jul 2024 07:07:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720706832; x=1721311632; h=mime-version:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+saMeEp6K8b2UuiArXvx/5umzNSvC8hLDSPiwl4HDHI=; b=j9UURndrM+k1szkUHL3ywHZj5nW0IEGj1aLFAEcTHkrDRrNNrY6KlrWDqdG1EgikpQ cYegG1Sb9EN0OuRUK0K90OaCSxq+KTgLs+63gIprcEXL4FacT8n778Nq84lN7cZn/wQt zq4I07dPLyJ3w27OVSTbYz/m5AZOctqYjsKFDRHSkRM0l/N36f4GRyy5ErHeSAqcYoTh gYE9ZZtCQYFJb95bNE59mlWx0REgQW3O0KUgIzkRNx1QQIwJ43XSri6c0T1Pb0aXR9OR m+4wd8XeQc1ynQcSsRTDW45DEHQAwNuRWsIsc4hgisGYurmRiaxKHtmbmz4+TIMB+Nvf BxXw== X-Gm-Message-State: AOJu0YzIv8CKpqLBztvvzFUZGGpSOSeSQvsiTozpeOggaCda2iu+8JMh MCF3I1POE3nbzUWHD2zRJ6kezLxSi2GK2UTjvdtgJVs1Vh0NbmB1yCtpWQSFPVhw5V1oZnaCg4Y VCImLRyxEoFwmEAkDTS+zLUP3oDWyLVlLWU7tADCTjSv0q1W+cG5J1jV4j6AR3hEYysnkgUA/tT OYjRtG+IRAlC+Wm3qZDFUJGLREUFp/ddavC2LT4w== X-Received: by 2002:a17:907:daa:b0:a77:d201:b88a with SMTP id a640c23a62f3a-a780b88499bmr746637866b.60.1720706831798; Thu, 11 Jul 2024 07:07:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFSj0IgLE1wQE2QY/3uQZy35/pdzw09Mi6nyeeB0+Kn+HmcVs519dVwDswadqlqiQaDdb3mBA== X-Received: by 2002:a17:907:daa:b0:a77:d201:b88a with SMTP id a640c23a62f3a-a780b88499bmr746632866b.60.1720706831163; Thu, 11 Jul 2024 07:07:11 -0700 (PDT) Received: from tpp.orcam.me.uk (tpp.orcam.me.uk. [81.187.245.177]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a780a7ff7bbsm260151866b.141.2024.07.11.07.07.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jul 2024 07:07:10 -0700 (PDT) Date: Thu, 11 Jul 2024 15:07:08 +0100 (BST) From: "Maciej W. Rozycki" To: libc-alpha@sourceware.org Subject: [PATCH] nptl: Fix extraneous testing run by tst-rseq-nptl in the test driver Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces~patchwork=sourceware.org@sourceware.org Fix an issue with commit 8f4632deb354 ("Linux: rseq registration tests") and prevent testing from being run in the process of the test driver itself rather than just the test child where one has been forked. The problem here is the unguarded use of a destructor to call a part of the testing. The destructor function, 'do_rseq_destructor_test' is called implicitly at program completion, however because it is associated with the executable itself rather than an individual process, it is called both in the test child *and* in the test driver itself. Prevent this from happening by providing a guard variable that only enables test invocation from 'do_rseq_destructor_test' in the process that has first run 'do_test'. Consequently extra testing is invoked from 'do_rseq_destructor_test' only once and in the correct process, regardless of the use or the lack of of the '--direct' option. Where called in the controlling test driver process that has neved called 'do_test' the destructor function silently returns right away without taking any further actions, letting the test driver fail gracefully where applicable. This arrangement prevents 'tst-rseq-nptl' from ever causing testing to hang forever and never complete, such as currently happening with the 'mips-linux-gnu' (o32 ABI) target. Reviewed-by: Adhemerval Zanella --- Hi, In the course of verifying changes for the BZ #27650 test case, posted separately, I have come across a couple of tests hanging forever that cause `mips-linux-gnu' (o32 ABI) testing to never complete unless the offending tests are killed by hand. This patch addresses this issue for the tst-rseq-nptl test. This was a bit tricky to debug as I saw no immediate cause as to the hang *despite* the test driver already being used by the test case. Eventually running via `strace' revealed the actual problem: wait4(16905, 0x7fffa930, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) --- SYS_4366() = 0 kill(-16905, SIGKILL) = 0 kill(16905, SIGKILL) = 0 wait4(16905, 0x7fffa5d0, WNOHANG|WSTOPPED, NULL) = 0 SYS_4265() = -1 ERRNO_516 ((null)) --- SIGCHLD (Child exited) --- SYS_4253() = 0 wait4(16905, [WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL], WNOHANG|WSTOPPED, NULL) = 16905 write(1, "Timed out: killed the child proc"..., 35) = 35 write(1, "\n", 1) = 1 brk(0) = 0x55591000 brk(0x555b2000) = 0x555b2000 SYS_4288() = 3 SYS_4366() = 0 SYS_4366() = 0 read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\7\0"..., 4096) = 1323 close(3) = 0 write(1, "Termination time: 2024-07-06T03:"..., 48) = 48 SYS_4367() = -1 EINVAL (Invalid argument) rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 16) = 0 SYS_4222() = 16904 getpid() = 16904 SYS_4266() = 0 --- SIGUSR1 (User defined signal 1) --- sigreturn() = 0 This was obtained with a slightly outdated `strace' binary, hence the missing decoding of some syscalls, however output produced is clear: the test child does get killed, the test driver reports what it is supposed to in this case, but then, hold on, what's up with that `rt_sigaction' call? OK, that pointed me at the right place, that is `do_rseq_destructor_test' having been marked with `__attribute__ ((destructor))'. Being a destructor the function is obviously implicitly called at program completion, and then by both the test child *and* the test driver process itself. Hence the call to `do_rseq_test' that hangs also causes the test driver to hang forever, preventing testing from ever completing. OK to apply (either now or past the freeze period)? Maciej --- sysdeps/unix/sysv/linux/tst-rseq-nptl.c | 9 +++++++++ 1 file changed, 9 insertions(+) glibc-tst-rseq-nptl-destructor.diff Index: glibc/sysdeps/unix/sysv/linux/tst-rseq-nptl.c =================================================================== --- glibc.orig/sysdeps/unix/sysv/linux/tst-rseq-nptl.c +++ glibc/sysdeps/unix/sysv/linux/tst-rseq-nptl.c @@ -28,6 +28,11 @@ #include #include +/* Set this in 'do_test' only so as to invoke the destructor test in + the test process only and not 'support_test_main' parent. Otherwise + the test harness may hang in the destructor if something goes wrong. */ +static int run_destructor_test; + #ifdef RSEQ_SIG # include # include @@ -236,6 +241,9 @@ do_rseq_test (void) static void __attribute__ ((destructor)) do_rseq_destructor_test (void) { + if (!run_destructor_test) + return; + /* Cannot use deferred failure reporting after main returns. */ if (do_rseq_test ()) FAIL_EXIT1 ("rseq not registered within destructor"); @@ -254,6 +262,7 @@ do_rseq_test (void) static int do_test (void) { + run_destructor_test = 1; return do_rseq_test (); }