From patchwork Wed Sep 8 02:52:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Malte Skarupke X-Patchwork-Id: 44898 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 498953858C60 for ; Wed, 8 Sep 2021 02:55:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 498953858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1631069725; bh=rbq2MrBJrpMsh9WMIq7uknKC68E2adVHYRHjWtS9nus=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=AoWcQyJk0OTykVnbVIlzNXlJvB/1K/q7PabrCNIstjlmHPp3ezTYTq3dppaZPHoT2 vRWVHr1jYvToVh5VXvFktklmIHk9jILC9NOAecLTJEH2luDmSF/9OLWn6wEKjkIXSl NwBeEe3D/moKwWtUPPuzUcYkhSyphkrvtpBOjibk= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mout.web.de (mout.web.de [212.227.15.14]) by sourceware.org (Postfix) with ESMTPS id ED5203858D35 for ; Wed, 8 Sep 2021 02:54:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED5203858D35 X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from auth2-smtp.messagingengine.com ([66.111.4.228]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1M8Bvz-1mKFDZ30k7-005O2I; Wed, 08 Sep 2021 04:54:14 +0200 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 78B0B27C0061; Tue, 7 Sep 2021 22:54:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 07 Sep 2021 22:54:13 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudefiedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhgggfestdekre dtredttdenucfhrhhomhepofgrlhhtvgcuufhkrghruhhpkhgvuceomhgrlhhtvghskhgr rhhuphhkvgesfigvsgdruggvqeenucggtffrrghtthgvrhhnpeevgfehffefffehleelie fftddvudffkedtkeduheeiueeugffgvdejgeduvdfgjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghlthgvshhkrghruhhpkhgvodhmvg hsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddutddujedtfedvleeiqdduuddvgedv keeiledqmhgrlhhtvghskhgrrhhuphhkvgeppeifvggsrdguvgesfhgrshhtmhgrihhlrd hfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Sep 2021 22:54:12 -0400 (EDT) To: libc-alpha@sourceware.org Subject: [PATCH v2 2/6] nptl: Remove the signal-stealing code. It is no longer needed. Date: Tue, 7 Sep 2021 22:52:35 -0400 Message-Id: <20210908025239.1326480-3-malteskarupke@web.de> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210908025239.1326480-1-malteskarupke@web.de> References: <20210908025239.1326480-1-malteskarupke@web.de> MIME-Version: 1.0 X-Provags-ID: V03:K1:pJMH/cMtfbFa5WtmOU+vbWgdLeIScgAZ8vbg3Aar/dr6RVTmH3D pWWw+uFW5MlDjYSnauEJNTnf/yj9zfFr577khZSU+yhAFDzma7kw3SjwFnJE46f2g70Wwj0 3t19HsifLKF38PIiU+BkoQVqiwRCxgOAxGysGebZDlOxmLxEDyFUO/vi4hhboKPpgOnc9NS ZzMYmYwroPieORJU8elpg== X-UI-Out-Filterresults: notjunk:1;V03:K0:rbZkGzESHdc=:jDV4Br3mZz7ohblhkue8Qf xMJCJzTNsXQUGRyvMHHIcV9Se4IfrjvYxayEcUA56nzU8ycRU+sEIc4sTJaRxYYUlgUrajPGA t/4rPLf412fRMAF9IwMYGviGFT581augwSHfx8QWU6x31Dt+URNnw72zGPVzdP69eiVOR0zN6 CPbi6rPdpujRACPBW5PuAhmKGOPTo4Njb3T3uP7vxkO/isDgP4ymLE9wpx6GgQMniov2Py0Wj U4GrnsGf2ShLqErT6puiExzerdO1bQDNK769jfXTv5YPPN+Mx7tAz+myTTvcLcqr4NR/j1Aq/ iLQP0C6PhEdi/IEStxz17KAAlCDoiuU+2TReToHJ0Tc8/s6ISmKJPxG1LhzieBA1kobeuLlWp h0tIM60p1wUrdKma4dWlBOaOSMzUmfn9glQbhx6eT4JsFlE8PVW1q4Xe+cBiIMso3K1RtSVbM 6Fzg8/Zx8LvK5wTC+os7MpqPl8rj8Z0yGhR1D7nNxJqt890j6j8uMsc6NA+EBdb4vAR7nqxMV aqup+sG46iXAsg9HoPARIjDRDWbK0wtxNqSxRufo1mb+hLyGkmUeG/k09EUfbMAebIjhF91Ml 6f6fEWDCokY6brkE+QLpj0IcZQIgXktKha0sFBwqRap0kNFKcNTiKroKq44akjLh+lOZBV1KR Mddm/oIscTUtOWhPKpeRd/TYRMM0C5p/FvKQfYppJxXeE35Jj3MZ9798LwCqqZp6uFpgj0Tcs /wE7S6S0mMm1t9WaxAp5k9qXSjoqKLXbVBNfxdNpmCX/nimRbcrJ/PmZ1hdGTEd3obtKl8e9i HiZ9fdfGHA5cmcnaYWI0NpvSsXRFxuDSqIuP5s/ym4Is1qHgFmlCLYMYx81t1/L/4RWPZCuEH hRAWoQjeiGQDy091R7Oq7gQA3fF5MYkwrb8sOF/Mvljm2NqIyNOF6xjMqHucZF51YcDCyeItl 5h9AKrTMtpCciZWYlwDaR53y6iP6FUwzDqQZ89P974xJpn9PuVq1LNX8+6P9rAropi/j7ImbA guv/lS5Q7amoBeKWVmlFXlxViIJjQaRafqa39xlpS/2Ejbf4EOuI59sfZC4RAnu9IoAG53CZc BKbdOQWFEUqthkXFlPa3qsaaOFOLf3oKCuSb7cjVtY3gkYcICHyawsB8g== X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Malte Skarupke via Libc-alpha From: Malte Skarupke Reply-To: Malte Skarupke Cc: Malte Skarupke , triegel@redhat.com, malteskarupke@fastmail.fm Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" After my last change, stealing of signals can no longer happen. This patch removes the code that handled the case when a signal was stolen. --- nptl/pthread_cond_wait.c | 63 ---------------------------------------- 1 file changed, 63 deletions(-) -- 2.25.1 diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c index cb674e2634..fb31090e26 100644 --- a/nptl/pthread_cond_wait.c +++ b/nptl/pthread_cond_wait.c @@ -528,69 +528,6 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, while (!atomic_compare_exchange_weak_acquire (cond->__data.__g_signals + g, &signals, signals - 2)); - /* We consumed a signal but we could have consumed from a more recent group - that aliased with ours due to being in the same group slot. If this - might be the case our group must be closed as visible through - __g1_start. */ - uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); - if (seq < (g1_start >> 1)) - { - /* We potentially stole a signal from a more recent group but we do not - know which group we really consumed from. - We do not care about groups older than current G1 because they are - closed; we could have stolen from these, but then we just add a - spurious wake-up for the current groups. - We will never steal a signal from current G2 that was really intended - for G2 because G2 never receives signals (until it becomes G1). We - could have stolen a signal from G2 that was conservatively added by a - previous waiter that also thought it stole a signal -- but given that - that signal was added unnecessarily, it's not a problem if we steal - it. - Thus, the remaining case is that we could have stolen from the current - G1, where "current" means the __g1_start value we observed. However, - if the current G1 does not have the same slot index as we do, we did - not steal from it and do not need to undo that. This is the reason - for putting a bit with G2's index into__g1_start as well. */ - if (((g1_start & 1) ^ 1) == g) - { - /* We have to conservatively undo our potential mistake of stealing - a signal. We can stop trying to do that when the current G1 - changes because other spinning waiters will notice this too and - __condvar_quiesce_and_switch_g1 has checked that there are no - futex waiters anymore before switching G1. - Relaxed MO is fine for the __g1_start load because we need to - merely be able to observe this fact and not have to observe - something else as well. - ??? Would it help to spin for a little while to see whether the - current G1 gets closed? This might be worthwhile if the group is - small or close to being closed. */ - unsigned int s = atomic_load_relaxed (cond->__data.__g_signals + g); - while (__condvar_load_g1_start_relaxed (cond) == g1_start) - { - /* Try to add a signal. We don't need to acquire the lock - because at worst we can cause a spurious wake-up. If the - group is in the process of being closed (LSB is true), this - has an effect similar to us adding a signal. */ - if (((s & 1) != 0) - || atomic_compare_exchange_weak_relaxed - (cond->__data.__g_signals + g, &s, s + 2)) - { - /* If we added a signal, we also need to add a wake-up on - the futex. We also need to do that if we skipped adding - a signal because the group is being closed because - while __condvar_quiesce_and_switch_g1 could have closed - the group, it might stil be waiting for futex waiters to - leave (and one of those waiters might be the one we stole - the signal from, which cause it to block using the - futex). */ - futex_wake (cond->__data.__g_signals + g, 1, private); - break; - } - /* TODO Back off. */ - } - } - } - done: /* Decrement group reference count and confirm that we have been woken. We do