From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 19A00385842F for ; Wed, 9 Feb 2022 17:10:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19A00385842F Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-471-2AlNGMp9PZWJoxaqXGZYOQ-1; Wed, 09 Feb 2022 12:10:18 -0500 X-MC-Unique: 2AlNGMp9PZWJoxaqXGZYOQ-1 Received: by mail-oo1-f70.google.com with SMTP id k16-20020a4aa5d0000000b002eaa82bf180so1955070oom.0 for ; Wed, 09 Feb 2022 09:10:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wSMgPQfyiEmLxRPVHYQU0qszeeNY2aFU/4DitRrwREU=; b=0wKk6OOCdMeDvAcR0GK30s8uGY63rw66SX74WMsR+OwJmMRvyC7my4Ltsdeg+9Pu40 V2HF+ad6t9QMNlt595CtTIVf+mnUarKZ6cl2bOxwSNKNvmBY5hwjRpLf2z94Gzqq9xYJ FNV5smr4OnJv6Y8hB3szPRMATHo0+nIAkv1aBFp6XPWs3A/nXzmBFHyGd8rKRlyFCH9A jUklRDdBkQkGUxdlNJE4GqV0fGrMUTK690hjd7xmzbQRoZXr8vGznhvzQ/Ewy6J2dm9F E1AvzWFBAtB9WHyUfvc82X5Uar20n8YhXF/cm9nybi3AMW4Cyd92LNLlMzhRJpAH1Tiq CTxQ== X-Gm-Message-State: AOAM531gYsNiiZfZEcVB2PfB3ZO92ZEZD66++aeo5MiUsbrd+1bCoM3V 9a83LFizGzqxcQC5OmmhHOwr/do8zjHsjA1EOWDCV4QlOOZB29TDB7v7UPzsVK2N/WYHm4/t5rs r2LhK5DEaOu1m7Oi7LkOzrqLftUkEZZk= X-Received: by 2002:a05:6808:1181:: with SMTP id j1mr1694735oil.182.1644426617845; Wed, 09 Feb 2022 09:10:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJxMaPypJqhWfWaQkOfD8VFsVsbjRbckS5HV/htL7v38ywY5ub73UX6901gO9P1kecGpBQEW/JFgbqn8eM+/5Cg= X-Received: by 2002:a05:6808:1181:: with SMTP id j1mr1694720oil.182.1644426617459; Wed, 09 Feb 2022 09:10:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Rodgers Date: Wed, 9 Feb 2022 09:10:06 -0800 Message-ID: Subject: Re: [PATCH] libstdc++: Fix deadlock in atomic wait [PR104442] To: Jonathan Wakely Cc: "libstdc++" , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="00000000000064f81f05d798e80a" X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, URI_HEX autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 17:10:24 -0000 --00000000000064f81f05d798e80a Content-Type: text/plain; charset="UTF-8" Updated patch. I reverted the memory order change (and will submit that as another patch) and fixed some spelling and grammar errors. On Wed, Feb 9, 2022 at 2:43 AM Jonathan Wakely wrote: > On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++ > wrote: > > > > This issue was observed as a deadloack in > > 29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is > > "laundered" (e.g. type T* does not suffice as a waitable address for the > > platform's native waiting primitive), the address waited is that of the > > _M_ver member of __waiter_pool_base, so several threads may wait on the > > same address for unrelated atomic's. As noted in the PR, the > > implementation correctly exits the wait for the thread who's data > > changed, but not for any other threads waiting on the same address. > > > > As noted in the PR the __waiter::_M_do_wait_v member was correctly > exiting > > but the other waiters were not reloaded the value of _M_ver before > > re-entering the wait. > > > > Moving the spin call inside the loop accomplishes this, and is > > consistent with the predicate accepting version of __waiter::_M_do_wait. > > There is a change to the memory order in _S_do_spin_v which is not > described in the commit msg or the changelog. Is that unintentional? > > (Aside: why do we even have _S_do_spin_v, it's called in exactly one > place, so could just be inlined into _M_do_spin_v, couldn't it?) > > --00000000000064f81f05d798e80a Content-Type: text/x-patch; charset="US-ASCII"; name="0001-libstdc-Fix-deadlock-in-atomic-wait-PR104442.patch" Content-Disposition: attachment; filename="0001-libstdc-Fix-deadlock-in-atomic-wait-PR104442.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzft3ywj0 RnJvbSBiMzkyODNkNTEwMDMwNWU3YTk1ZDU5MzI0MDU5ZGU5OTUyZDNhODU4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUaG9tYXMgUm9kZ2VycyA8cm9kZ2VydEBhcHBsaWFudG9sb2d5 LmNvbT4KRGF0ZTogVHVlLCA4IEZlYiAyMDIyIDE2OjMzOjM2IC0wODAwClN1YmplY3Q6IFtQQVRD SF0gbGlic3RkYysrOiBGaXggZGVhZGxvY2sgaW4gYXRvbWljIHdhaXQgW1BSMTA0NDQyXQoKVGhp cyBpc3N1ZSB3YXMgb2JzZXJ2ZWQgYXMgYSBkZWFkbG9jayBpbgoyOV9hdG9taWNzL2F0b21pYy93 YWl0X25vdGlmeS8xMDAzMzQuY2Mgb24gdnh3b3Jrcy4gV2hlbiBhIHdhaXQgaXMKImxhdW5kZXJl ZCIgKGUuZy4gdHlwZSBUKiBkb2VzIG5vdCBzdWZmaWNlIGFzIGEgd2FpdGFibGUgYWRkcmVzcyBm b3IgdGhlCnBsYXRmb3JtJ3MgbmF0aXZlIHdhaXRpbmcgcHJpbWl0aXZlKSwgdGhlIGFkZHJlc3Mg d2FpdGVkIGlzIHRoYXQgb2YgdGhlCl9NX3ZlciBtZW1iZXIgb2YgX193YWl0ZXJfcG9vbF9iYXNl LCBzbyBzZXZlcmFsIHRocmVhZHMgbWF5IHdhaXQgb24gdGhlCnNhbWUgYWRkcmVzcyBmb3IgdW5y ZWxhdGVkIGF0b21pYzxUPiBvYmplY3RzLiBBcyBub3RlZCBpbiB0aGUgUFIsIHRoZQppbXBsZW1l bnRhdGlvbiBjb3JyZWN0bHkgZXhpdHMgdGhlIHdhaXQgZm9yIHRoZSB0aHJlYWQgd2hvc2UgZGF0 YQpjaGFuZ2VkLCBidXQgbm90IGZvciBhbnkgb3RoZXIgdGhyZWFkcyB3YWl0aW5nIG9uIHRoZSBz YW1lIGFkZHJlc3MuCgpBcyBub3RlZCBpbiB0aGUgUFIgdGhlIF9fd2FpdGVyOjpfTV9kb193YWl0 X3YgbWVtYmVyIHdhcyBjb3JyZWN0bHkgZXhpdGluZwpidXQgdGhlIG90aGVyIHdhaXRlcnMgd2Vy ZSBub3QgcmVsb2FkaW5nIHRoZSB2YWx1ZSBvZiBfTV92ZXIgYmVmb3JlCnJlLWVudGVyaW5nIHRo ZSB3YWl0LgoKTW92aW5nIHRoZSBzcGluIGNhbGwgaW5zaWRlIHRoZSBsb29wIGFjY29tcGxpc2hl cyB0aGlzLCBhbmQgaXMKY29uc2lzdGVudCB3aXRoIHRoZSBwcmVkaWNhdGUgYWNjZXB0aW5nIHZl cnNpb24gb2YgX193YWl0ZXI6Ol9NX2RvX3dhaXQuCgpsaWJzdGRjKystdjMvQ2hhbmdlTG9nOgoK CVBSIGxpYnN0ZGMrKy8xMDQ0NDIKCSogaW5jbHVkZS9iaXRzL2F0b21pY193YWl0LmggKF9fd2Fp dGVyOjpfTV9kb193YWl0X3YpOiBNb3ZlIHNwaW4KCSBsb29wIGluc2lkZSBkbyBsb29wIHNvIHRo YXQgdGhyZWFkcyBmYWlsaW5nIHRoZSB3YWl0LCByZWxvYWQKCSBfTV92ZXIuCi0tLQogbGlic3Rk YysrLXYzL2luY2x1ZGUvYml0cy9hdG9taWNfd2FpdC5oIHwgNyArKystLS0tCiAxIGZpbGUgY2hh bmdlZCwgMyBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpYnN0 ZGMrKy12My9pbmNsdWRlL2JpdHMvYXRvbWljX3dhaXQuaCBiL2xpYnN0ZGMrKy12My9pbmNsdWRl L2JpdHMvYXRvbWljX3dhaXQuaAppbmRleCBkN2RlMGQ3ZWI5ZS4uNmNlN2Y5MzQzY2YgMTAwNjQ0 Ci0tLSBhL2xpYnN0ZGMrKy12My9pbmNsdWRlL2JpdHMvYXRvbWljX3dhaXQuaAorKysgYi9saWJz dGRjKystdjMvaW5jbHVkZS9iaXRzL2F0b21pY193YWl0LmgKQEAgLTM4OCwxMiArMzg4LDExIEBA IF9HTElCQ1hYX0JFR0lOX05BTUVTUEFDRV9WRVJTSU9OCiAJICB2b2lkCiAJICBfTV9kb193YWl0 X3YoX1RwIF9fb2xkLCBfVmFsRm4gX192Zm4pCiAJICB7Ci0JICAgIF9fcGxhdGZvcm1fd2FpdF90 IF9fdmFsOwotCSAgICBpZiAoX19iYXNlX3R5cGU6Ol9NX2RvX3NwaW5fdihfX29sZCwgX192Zm4s IF9fdmFsKSkKLQkgICAgICByZXR1cm47Ci0KIAkgICAgZG8KIAkgICAgICB7CisJCV9fcGxhdGZv cm1fd2FpdF90IF9fdmFsOworCQlpZiAoX19iYXNlX3R5cGU6Ol9NX2RvX3NwaW5fdihfX29sZCwg X192Zm4sIF9fdmFsKSkKKwkJICByZXR1cm47CiAJCV9fYmFzZV90eXBlOjpfTV93Ll9NX2RvX3dh aXQoX19iYXNlX3R5cGU6Ol9NX2FkZHIsIF9fdmFsKTsKIAkgICAgICB9CiAJICAgIHdoaWxlIChf X2RldGFpbDo6X19hdG9taWNfY29tcGFyZShfX29sZCwgX192Zm4oKSkpOwotLSAKMi4zNC4xCgo= --00000000000064f81f05d798e80a--