From patchwork Thu Jun 12 09:56:32 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64821 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7ED8C61CE8 for ; Thu, 12 Jun 2025 09:57:13 +0000 (UTC) Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by mx.groups.io with SMTP id smtpd.web10.9245.1749722232005168600 for ; Thu, 12 Jun 2025 02:57:12 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.166.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250810.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C4SVJD006799 for ; Thu, 12 Jun 2025 02:57:11 -0700 Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10on2045.outbound.protection.outlook.com [40.107.93.45]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474gq45akd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 02:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DCCX+2p7loNAYQEHvS6ld4RhGXNfE/53t+mQf1bBk9oobwxSuGF/1cnYFOWuUBZTofnTYDRnMUx1Tfhq54K1lajAL1gozcIys3nIJNCuADR+sbrrSsF6jaEzB9+1wn9Fw/huYg6nWNenTUyrOG7nHd2LlwUeARjLO/KS/Qrxt687+9KNO514Rny4Yt+QwjFTfrQ0d04/3Jk6xFti5DRqwOafPCiuqJMhOoKswlS/jp3J1j9tKdvwOBKJDqiHybk497nf6kismxZuYA1uLrqpi7xMCU8+jDGyc4MmUAPEbE3MX2/HBtyB4acg/J6DXrJXMRSmRZetOraINcpnFuqsUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lqU29vl2jS4Bwa0KM320uFmzE4k6MxGCG/8YpguYwP8=; b=oi1W7tVHoovpmUKEOlcUkm+SAzjeF9MdGwgRG4kmo1SD+nktcDWjWYrkGWTJd8Z6js91v0eodpiSEtwl4oYtX7dzHf4+Mh8crogeANjq8CpMKrep9KLRXtjlSUpAoPiKIuPO3cY+oljdfmPBS98oobN8LMxCbnzqrDqRXcLsU1oBOyjgt0iE858Vor97do640DxWIuzbCxU+99dl+fCwC79AiyY9+I952GKBDhqV7o0aV8ds5FRik1OuP2LQ0BboNcympK+ufDCpOBWwwFLQD6Zm9Z8pFKgopb2XwOq/yjk6+j4Ljakw0VTbO43UfeufzsBT94Jdaj/dL52u/Yd1og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:09 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:09 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 1/8] pthreads NPTL: lost wakeup fix 2 Date: Thu, 12 Jun 2025 02:56:32 -0700 Message-ID: <20250612095639.3630518-2-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: add88d6c-50de-45c4-b476-08dda9977ef2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: wen9AMFGE6MA4h6xmqCAW3Stu5b5jiXvOV0SGPxFF8gckqaEjVFmQBmESv0iYKb4oyXWfA7Fmif/h3Yl7+5dPX5/v1yYRn+crWFZ/w5w2oeYME2vHc4QDx86l90uAN9IWOGDCQb/t2UpkBD+4EDF60QwUA1/q8pwimXFxknCiF8To1LPa+FDt8x5oY5Mzcb3mOeUzbj9s2qLH4uI3ACHRKO6KUq2DzOMUnGPxsZjygh10gXcm7PTJhnAqLNGR4GtvgX9SyRe3xemZwYLuDKx2YoFbSCPEBHj/AcsSgdYrgxlmybwFAO/POamMr9AurJpWgnSSeGT+ePFr0D2RP+UPbJ1/nRtL5CuHcgjC4ctTrvEsw9duMi/+80DqCs20zbJx1N2OnmXCNyVybE3F7y/QKR8Fw+6AvVGiK5dGAZeakgnF/viZwXXah8+cVOEMVZtMDMvSfNusBObD0ekBaBput+uu0yqLQ66Q2GQ6ePozGiVdDtDSA1UvGshrTQaR/C7ths7xnyAwqdsd9jnZE5P0pFioJmHZRaAIgANT1bNBGB7IIh+kzJ615aMeWX66mn5Zomf+oWqjkrB4lYZmaZVIxDM7LhPGepddsIMBzBdzpek6s2yRrYtEUIfdo6ysa4gyMnc2+Q+3Um1Ln4saNpp5SUVv+CLAgnxoN43K24GJFwUaVj6nWB5Vs7yS0zMWVmamOBxSng3T/TQzASNwRQnoPUR+9gwhmom+7fnwzdOEkSqbKHr2x36hh0VPfGhGU0Hg8lVYiomuiHHwbSzn+abTqGnJp1psP8UQyoTWg+qHKNilzdipLpkFM/rQWdAjwmMDCSAhxbRICUa3ioSgzhwvFWsbhovwEgBe6q4nfbQCa1Qgx0++54dCRIJA3DGiiOPHZzfUKEXunlaS/p6q+/1A/ZMLT1PwBN0+znhjyhlPDLidszcc7el/IrASby39PXePzzUZCB/9LEZP94swNeVnMa65+JM7995SoDNvhorsPOfW4xuP5Ou/9m+LJh4c3Hvje7B/yLyTchFk/93qOpEi7CRz3F1eeKSRFmKbxK7gCBrsUAYAZuokhj1PDk1eP4CjzBbsfcupNFRyz4RBUeLv1xTSXX6/i0nAbkBMROgS9yd4GpcoougntPjoK/yK18ZtZ0M7epv8smQ0tOgtQnnR+ECpOHpfjCJx5maiU9LVDwS6z06rRyHbyRz+3LRc6En8fI7P1crusCty+I42fNgu86VJ+uziK3JW6R6LMEC28VNKhyIE7oUysDhmVlf5AExfBhFEAllDWdirWLD7OARC+BvtQ4un6EsZUuDWZ4cAlQYgufYDS9G9zY85imdWORINLbHsz9vdEp1ueoNCWrLM36JKFcW1t/rJZnYgm5Ju3cNLkAXTqb30D4N7KC79WlukssztfeAfoz+QUtWiVszIDY+cxB7i/9yY4GonZUGd1o21tJqqqVDtu18y4NfVFcuIQBot0yloF1Oo2in1lGGqer6Dx9g216aAp67/HP1L5w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: g0+QQ3m0SpSiWk2CEbBJJogkC/IPgFYkNtz950qgbWw1ZgBnusHXZU3hbnQ4AVteQLex8vtUmNUIqdB57E3eXZ3BhuqDXnWkCi19pkF+UywXZjehj8vTBfpGYytkMViOseT2DqQ1m+/dP6RFZsB7of3MqJDg+u73F1gEQCwdvZfzMInw9GUih941WhT5RCVvs1jzz301rcbAqKzUz5TL14LBXLnaGcxCCdPRVtIHpgReJhww4mX8aOoi2eeBGZYGiT23ln2qZ4anyMYWCw/FEocy9oyrfNNlF6EhZ9Bkk5SvI5Y+C3xWh1CaXLdex99lL9JdEFtxiCg7M2F8rUteNlZ/x+ux1K8PzXilOonJCpgFDGogQiL4Q1/Zg8rmtgxgRFzT/x4WADogReMhu7zPx2ROM8rM+SvRhVp45MxoyC7aut0m8pIutgpqVFk5HWDlkFpPXmVkSKmp27evZ1nGRDufg0M0YKXssDUtulRkxp+OXrL6AHaqq3Vn4YmvMKLbQQrqsUNuALYZMQn38GqeLIQszck//ZNA3Avsw7a6INYp0hhgKOvZ2rnGzYPcvdjTi/KUD8MUgJJZ/2kxW+NIitCKNsgwN3jwzIeW36l+NpavUTPHRpt1Q+DcbmCx0s5I0cKSV9zYD4g7o3LTHzaSlMPMvFpEz3YLiFyRYHm8wUEuWPy5k0c1/kCxUcMP8hHRs4+OcDOqkjVV3LNQz5LCHpYGiFadOtus55Sn4FJkTTmpvLMTVZ9prNUIAU4FgOknqv+m1VtkqG5kWUQd+tDUwIA3ep5nGIKpJGFoHTUoKfHMlvpmvPCCg1W5dvkJNY2joq9pLt1M0xdYMee2gUvitk7a5CnP4UOlVj36ljvKJASdRmUdeOMLXTxrczeLqv9c/y6jYMbx+OYscSmabqiiufitr0Fv5clqkE33Sn63rcy3aaWuaMd4ffaaA/C/oAmk7qQzoDsO1wfMDxeb4ObC+3pYKDxhLAjjT2hGYi4mYbVxHFVEZEsxUzRf+m4q/uiaE8ywdmOuXF0DJDEIc3zmSRYvoLMYk/r1nJPt/sea1bIX2TR+x9LuEt4PmVB1/705PhZLz3V+SA78Yio7y/3SACzMwUfwj94OvH7r1uRkL/TeYGvgo8jGNuhxyiX+SUbZpRfmcjaDHH0I8kDxUv057qkBUfxIvdd/fFoImueCr2LJVYqcCc42JjT0/r3gdQ7diRIouTYXgOr0oucuKfahGMrCoy3UagaUK5+oIyv2nF+j+7UbhawjJrxOKs498Y3nRS9jAgugEM5GFEhqXrZ1v5jBXke/IT+/Po15VulugyuKV5bE9Ka1Js4jNrH3mGJr8Kb9aT0CES0MjLCZSvqaCb5pE7E2WUCJAFONY//RENXildBKm2JsWue6WFwf1IgncAS8jeMo6fLrdkcJlmSz/BTRy8HqrWdzcyI/Gr+MU/iXo6Ao8UXmxP14JXEXoKj6QKx/IwACY9yWDmMCwRFltvacBtX5ZrbQbYEeqKF05HcqOlfgECSytomMEe8FloN1dDF4omAXkvb5D74nxhQSlurYO6t4gZ3ZeWFF3gd0XrwpNnxInHK6iIvIsyBKkG2JxcGORCEppSjgxgxeOBsG/g== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: add88d6c-50de-45c4-b476-08dda9977ef2 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:09.3422 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TWgKsSq83Dko21XTQu9ML9+2QAef4kHfn0+Vilif07OziE6Sg9WL9uaHQXplwCjJ6+1m8kyvOQR60i+FrdBS4QeSwuoyVeSglnoQbnGHop8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=Qrde3Uyd c=1 sm=1 tr=0 ts=684aa477 cx=c_pps a=Ns4bprCil9VHDTMiZxHROw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=-y7sjS4E6xoPhqQzj00A:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-GUID: zKs1TTxazXxjfmDmy4_0gOZ6CrwbJd-r X-Proofpoint-ORIG-GUID: zKs1TTxazXxjfmDmy4_0gOZ6CrwbJd-r X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfX7n9tUvVdXbr6 lVxJ3TuDCSlS53t7g8vKKwb+i+PTeinzjsETEbl5Z1F8CpCDOmatxP5+/6szVgZwL7o1i0Q1EwL +ib7mXNLUZSujLLgylbYT3BDXxIVs7bJmz/CAP1hh9LGK5w4XFjPOJO0XVyaBdB2Dec0PbDhkp9 DkQ3is0YmN9UTn5I1bw8KSsKfQ1RZLVbScb2we77BuPYrlhV9a/gnAno2x02ZijHZy1lteLBJIR WxYbImbu+9904c2lTMxuIz+37tP1sA0jE3eEzBjfK3RbW3gvawp3DTnRniJnPdOk5Ycn7WiMnuR 5BarfScuyNn7iomJMqTmxwZxLWh0ZPSwAQ7DGwFBH/CFDpVHRk3I3qTll2kE+3RaPScFUrO+j4j lb1R7Q0DP66ruaLeOAAONCNFrh1nJiJeCtQI4uUEi3MxDtTQXuohb8/ChD6n3hQHPq/M27W8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 suspectscore=0 impostorscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 phishscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:13 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218493 From: Sunil Dora The following commits have been cherry-picked from Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [1db84775f831a1494993ce9c118deaf9537cc50a] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-1.patch | 453 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 454 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-1.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-1.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-1.patch new file mode 100644 index 0000000000..67a6fa1e62 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-1.patch @@ -0,0 +1,453 @@ +From 6f030a8faf242b897e714cb77c65254b14682cfc Mon Sep 17 00:00:00 2001 +From: Frank Barrus +Date: Mon, 9 Jun 2025 02:32:52 -0700 +Subject: [PATCH] pthreads NPTL: lost wakeup fix 2 + +This fixes the lost wakeup (from a bug in signal stealing) with a change +in the usage of g_signals[] in the condition variable internal state. +It also completely eliminates the concept and handling of signal stealing, +as well as the need for signalers to block to wait for waiters to wake +up every time there is a G1/G2 switch. This greatly reduces the average +and maximum latency for pthread_cond_signal. + +The g_signals[] field now contains a signal count that is relative to +the current g1_start value. Since it is a 32-bit field, and the LSB is +still reserved (though not currently used anymore), it has a 31-bit value +that corresponds to the low 31 bits of the sequence number in g1_start. +(since g1_start also has an LSB flag, this means bits 31:1 in g_signals +correspond to bits 31:1 in g1_start, plus the current signal count) + +By making the signal count relative to g1_start, there is no longer +any ambiguity or A/B/A issue, and thus any checks before blocking, +including the futex call itself, are guaranteed not to block if the G1/G2 +switch occurs, even if the signal count remains the same. This allows +initially safely blocking in G2 until the switch to G1 occurs, and +then transitioning from G1 to a new G1 or G2, and always being able to +distinguish the state change. This removes the race condition and A/B/A +problems that otherwise ocurred if a late (pre-empted) waiter were to +resume just as the futex call attempted to block on g_signal since +otherwise there was no last opportunity to re-check things like whether +the current G1 group was already closed. + +By fixing these issues, the signal stealing code can be eliminated, +since there is no concept of signal stealing anymore. The code to block +for all waiters to exit g_refs can also be removed, since any waiters +that are still in the g_refs region can be guaranteed to safely wake +up and exit. If there are still any left at this time, they are all +sent one final futex wakeup to ensure that they are not blocked any +longer, but there is no need for the signaller to block and wait for +them to wake up and exit the g_refs region. + +The signal count is then effectively "zeroed" but since it is now +relative to g1_start, this is done by advancing it to a new value that +can be observed by any pending blocking waiters. Any late waiters can +always tell the difference, and can thus just cleanly exit if they are +in a stale G1 or G2. They can never steal a signal from the current +G1 if they are not in the current G1, since the signal value that has +to match in the cmpxchg has the low 31 bits of the g1_start value +contained in it, and that's first checked, and then it won't match if +there's a G1/G2 change. + +Note: the 31-bit sequence number used in g_signals is designed to +handle wrap-around when checking the signal count, but if the entire +31-bit wraparound (2 billion signals) occurs while there is still a +late waiter that has not yet resumed, and it happens to then match +the current g1_start low bits, and the pre-emption occurs after the +normal "closed group" checks (which are 64-bit) but then hits the +futex syscall and signal consuming code, then an A/B/A issue could +still result and cause an incorrect assumption about whether it +should block. This particular scenario seems unlikely in practice. +Note that once awake from the futex, the waiter would notice the +closed group before consuming the signal (since that's still a 64-bit +check that would not be aliased in the wrap-around in g_signals), +so the biggest impact would be blocking on the futex until the next +full wakeup from a G1/G2 switch. + +The following commits have been cherry-picked from Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [1db84775f831a1494993ce9c118deaf9537cc50a] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_common.c | 105 +++++++++------------------ + nptl/pthread_cond_wait.c | 144 ++++++++++++------------------------- + 2 files changed, 81 insertions(+), 168 deletions(-) + +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index fb035f72..a55eee3e 100644 +--- a/nptl/pthread_cond_common.c ++++ b/nptl/pthread_cond_common.c +@@ -201,7 +201,6 @@ static bool __attribute__ ((unused)) + __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + unsigned int *g1index, int private) + { +- const unsigned int maxspin = 0; + unsigned int g1 = *g1index; + + /* If there is no waiter in G2, we don't do anything. The expression may +@@ -222,84 +221,46 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + * New waiters arriving concurrently with the group switching will all go + into G2 until we atomically make the switch. Waiters existing in G2 + are not affected. +- * Waiters in G1 will be closed out immediately by setting a flag in +- __g_signals, which will prevent waiters from blocking using a futex on +- __g_signals and also notifies them that the group is closed. As a +- result, they will eventually remove their group reference, allowing us +- to close switch group roles. */ +- +- /* First, set the closed flag on __g_signals. This tells waiters that are +- about to wait that they shouldn't do that anymore. This basically +- serves as an advance notificaton of the upcoming change to __g1_start; +- waiters interpret it as if __g1_start was larger than their waiter +- sequence position. This allows us to change __g1_start after waiting +- for all existing waiters with group references to leave, which in turn +- makes recovery after stealing a signal simpler because it then can be +- skipped if __g1_start indicates that the group is closed (otherwise, +- we would have to recover always because waiters don't know how big their +- groups are). Relaxed MO is fine. */ +- atomic_fetch_or_relaxed (cond->__data.__g_signals + g1, 1); +- +- /* Wait until there are no group references anymore. The fetch-or operation +- injects us into the modification order of __g_refs; release MO ensures +- that waiters incrementing __g_refs after our fetch-or see the previous +- changes to __g_signals and to __g1_start that had to happen before we can +- switch this G1 and alias with an older group (we have two groups, so +- aliasing requires switching group roles twice). Note that nobody else +- can have set the wake-request flag, so we do not have to act upon it. +- +- Also note that it is harmless if older waiters or waiters from this G1 +- get a group reference after we have quiesced the group because it will +- remain closed for them either because of the closed flag in __g_signals +- or the later update to __g1_start. New waiters will never arrive here +- but instead continue to go into the still current G2. */ +- unsigned r = atomic_fetch_or_release (cond->__data.__g_refs + g1, 0); +- while ((r >> 1) > 0) +- { +- for (unsigned int spin = maxspin; ((r >> 1) > 0) && (spin > 0); spin--) +- { +- /* TODO Back off. */ +- r = atomic_load_relaxed (cond->__data.__g_refs + g1); +- } +- if ((r >> 1) > 0) +- { +- /* There is still a waiter after spinning. Set the wake-request +- flag and block. Relaxed MO is fine because this is just about +- this futex word. +- +- Update r to include the set wake-request flag so that the upcoming +- futex_wait only blocks if the flag is still set (otherwise, we'd +- violate the basic client-side futex protocol). */ +- r = atomic_fetch_or_relaxed (cond->__data.__g_refs + g1, 1) | 1; +- +- if ((r >> 1) > 0) +- futex_wait_simple (cond->__data.__g_refs + g1, r, private); +- /* Reload here so we eventually see the most recent value even if we +- do not spin. */ +- r = atomic_load_relaxed (cond->__data.__g_refs + g1); +- } +- } +- /* Acquire MO so that we synchronize with the release operation that waiters +- use to decrement __g_refs and thus happen after the waiters we waited +- for. */ +- atomic_thread_fence_acquire (); ++ * Waiters in G1 will be closed out immediately by the advancing of ++ __g_signals to the next "lowseq" (low 31 bits of the new g1_start), ++ which will prevent waiters from blocking using a futex on ++ __g_signals since it provides enough signals for all possible ++ remaining waiters. As a result, they can each consume a signal ++ and they will eventually remove their group reference. */ + + /* Update __g1_start, which finishes closing this group. The value we add + will never be negative because old_orig_size can only be zero when we + switch groups the first time after a condvar was initialized, in which +- case G1 will be at index 1 and we will add a value of 1. See above for +- why this takes place after waiting for quiescence of the group. ++ case G1 will be at index 1 and we will add a value of 1. + Relaxed MO is fine because the change comes with no additional + constraints that others would have to observe. */ + __condvar_add_g1_start_relaxed (cond, + (old_orig_size << 1) + (g1 == 1 ? 1 : - 1)); + +- /* Now reopen the group, thus enabling waiters to again block using the +- futex controlled by __g_signals. Release MO so that observers that see +- no signals (and thus can block) also see the write __g1_start and thus +- that this is now a new group (see __pthread_cond_wait_common for the +- matching acquire MO loads). */ +- atomic_store_release (cond->__data.__g_signals + g1, 0); ++ unsigned int lowseq = ((old_g1_start + old_orig_size) << 1) & ~1U; ++ ++ /* If any waiters still hold group references (and thus could be blocked), ++ then wake them all up now and prevent any running ones from blocking. ++ This is effectively a catch-all for any possible current or future ++ bugs that can allow the group size to reach 0 before all G1 waiters ++ have been awakened or at least given signals to consume, or any ++ other case that can leave blocked (or about to block) older waiters.. */ ++ if ((atomic_fetch_or_release (cond->__data.__g_refs + g1, 0) >> 1) > 0) ++ { ++ /* First advance signals to the end of the group (i.e. enough signals ++ for the entire G1 group) to ensure that waiters which have not ++ yet blocked in the futex will not block. ++ Note that in the vast majority of cases, this should never ++ actually be necessary, since __g_signals will have enough ++ signals for the remaining g_refs waiters. As an optimization, ++ we could check this first before proceeding, although that ++ could still leave the potential for futex lost wakeup bugs ++ if the signal count was non-zero but the futex wakeup ++ was somehow lost. */ ++ atomic_store_release (cond->__data.__g_signals + g1, lowseq); ++ ++ futex_wake (cond->__data.__g_signals + g1, INT_MAX, private); ++ } + + /* At this point, the old G1 is now a valid new G2 (but not in use yet). + No old waiter can neither grab a signal nor acquire a reference without +@@ -311,6 +272,10 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + g1 ^= 1; + *g1index ^= 1; + ++ /* Now advance the new G1 g_signals to the new lowseq, giving it ++ an effective signal count of 0 to start. */ ++ atomic_store_release (cond->__data.__g_signals + g1, lowseq); ++ + /* These values are just observed by signalers, and thus protected by the + lock. */ + unsigned int orig_size = wseq - (old_g1_start + old_orig_size); +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index 20c348a5..1cb3dbf7 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -238,9 +238,7 @@ __condvar_cleanup_waiting (void *arg) + signaled), and a reference count. + + The group reference count is used to maintain the number of waiters that +- are using the group's futex. Before a group can change its role, the +- reference count must show that no waiters are using the futex anymore; this +- prevents ABA issues on the futex word. ++ are using the group's futex. + + To represent which intervals in the waiter sequence the groups cover (and + thus also which group slot contains G1 or G2), we use a 64b counter to +@@ -300,11 +298,12 @@ __condvar_cleanup_waiting (void *arg) + last reference. + * Reference count used by waiters concurrently with signalers that have + acquired the condvar-internal lock. +- __g_signals: The number of signals that can still be consumed. ++ __g_signals: The number of signals that can still be consumed, relative to ++ the current g1_start. (i.e. bits 31 to 1 of __g_signals are bits ++ 31 to 1 of g1_start with the signal count added) + * Used as a futex word by waiters. Used concurrently by waiters and + signalers. +- * LSB is true iff this group has been completely signaled (i.e., it is +- closed). ++ * LSB is currently reserved and 0. + __g_size: Waiters remaining in this group (i.e., which have not been + signaled yet. + * Accessed by signalers and waiters that cancel waiting (both do so only +@@ -328,18 +327,6 @@ __condvar_cleanup_waiting (void *arg) + sufficient because if a waiter can see a sufficiently large value, it could + have also consume a signal in the waiters group. + +- Waiters try to grab a signal from __g_signals without holding a reference +- count, which can lead to stealing a signal from a more recent group after +- their own group was already closed. They cannot always detect whether they +- in fact did because they do not know when they stole, but they can +- conservatively add a signal back to the group they stole from; if they +- did so unnecessarily, all that happens is a spurious wake-up. To make this +- even less likely, __g1_start contains the index of the current g2 too, +- which allows waiters to check if there aliasing on the group slots; if +- there wasn't, they didn't steal from the current G1, which means that the +- G1 they stole from must have been already closed and they do not need to +- fix anything. +- + It is essential that the last field in pthread_cond_t is __g_signals[1]: + The previous condvar used a pointer-sized field in pthread_cond_t, so a + PTHREAD_COND_INITIALIZER from that condvar implementation might only +@@ -435,6 +422,9 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + { + while (1) + { ++ uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); ++ unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; ++ + /* Spin-wait first. + Note that spinning first without checking whether a timeout + passed might lead to what looks like a spurious wake-up even +@@ -446,35 +436,45 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + having to compare against the current time seems to be the right + choice from a performance perspective for most use cases. */ + unsigned int spin = maxspin; +- while (signals == 0 && spin > 0) ++ while (spin > 0 && ((int)(signals - lowseq) < 2)) + { + /* Check that we are not spinning on a group that's already + closed. */ +- if (seq < (__condvar_load_g1_start_relaxed (cond) >> 1)) +- goto done; ++ if (seq < (g1_start >> 1)) ++ break; + + /* TODO Back off. */ + + /* Reload signals. See above for MO. */ + signals = atomic_load_acquire (cond->__data.__g_signals + g); ++ g1_start = __condvar_load_g1_start_relaxed (cond); ++ lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + spin--; + } + +- /* If our group will be closed as indicated by the flag on signals, +- don't bother grabbing a signal. */ +- if (signals & 1) +- goto done; +- +- /* If there is an available signal, don't block. */ +- if (signals != 0) ++ if (seq < (g1_start >> 1)) ++ { ++ /* If the group is closed already, ++ then this waiter originally had enough extra signals to ++ consume, up until the time its group was closed. */ ++ goto done; ++ } ++ ++ /* If there is an available signal, don't block. ++ If __g1_start has advanced at all, then we must be in G1 ++ by now, perhaps in the process of switching back to an older ++ G2, but in either case we're allowed to consume the available ++ signal and should not block anymore. */ ++ if ((int)(signals - lowseq) >= 2) + break; + + /* No signals available after spinning, so prepare to block. + We first acquire a group reference and use acquire MO for that so + that we synchronize with the dummy read-modify-write in + __condvar_quiesce_and_switch_g1 if we read from that. In turn, +- in this case this will make us see the closed flag on __g_signals +- that designates a concurrent attempt to reuse the group's slot. ++ in this case this will make us see the advancement of __g_signals ++ to the upcoming new g1_start that occurs with a concurrent ++ attempt to reuse the group's slot. + We use acquire MO for the __g_signals check to make the + __g1_start check work (see spinning above). + Note that the group reference acquisition will not mask the +@@ -482,15 +482,24 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + an atomic read-modify-write operation and thus extend the release + sequence. */ + atomic_fetch_add_acquire (cond->__data.__g_refs + g, 2); +- if (((atomic_load_acquire (cond->__data.__g_signals + g) & 1) != 0) +- || (seq < (__condvar_load_g1_start_relaxed (cond) >> 1))) ++ signals = atomic_load_acquire (cond->__data.__g_signals + g); ++ g1_start = __condvar_load_g1_start_relaxed (cond); ++ lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; ++ ++ if (seq < (g1_start >> 1)) + { +- /* Our group is closed. Wake up any signalers that might be +- waiting. */ ++ /* group is closed already, so don't block */ + __condvar_dec_grefs (cond, g, private); + goto done; + } + ++ if ((int)(signals - lowseq) >= 2) ++ { ++ /* a signal showed up or G1/G2 switched after we grabbed the refcount */ ++ __condvar_dec_grefs (cond, g, private); ++ break; ++ } ++ + // Now block. + struct _pthread_cleanup_buffer buffer; + struct _condvar_cleanup_buffer cbuffer; +@@ -501,7 +510,7 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + __pthread_cleanup_push (&buffer, __condvar_cleanup_waiting, &cbuffer); + + err = __futex_abstimed_wait_cancelable64 ( +- cond->__data.__g_signals + g, 0, clockid, abstime, private); ++ cond->__data.__g_signals + g, signals, clockid, abstime, private); + + __pthread_cleanup_pop (&buffer, 0); + +@@ -524,6 +533,8 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + signals = atomic_load_acquire (cond->__data.__g_signals + g); + } + ++ if (seq < (__condvar_load_g1_start_relaxed (cond) >> 1)) ++ goto done; + } + /* Try to grab a signal. Use acquire MO so that we see an up-to-date value + of __g1_start below (see spinning above for a similar case). In +@@ -532,69 +543,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: + + /* Confirm that we have been woken. We do that before acquiring the mutex +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index 9073e04537..2d23c17a48 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -61,6 +61,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0022-sysdeps-gnu-configure.ac-Set-libc_cv_rootsbindir-onl.patch \ file://0023-timezone-Make-shell-interpreter-overridable-in-tzsel.patch \ file://0024-fix-create-thread-failed-in-unprivileged-process-BZ-.patch \ + file://0026-PR25847-1.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:33 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64822 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8750C71136 for ; Thu, 12 Jun 2025 09:57:23 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web10.9247.1749722242088031295 for ; Thu, 12 Jun 2025 02:57:22 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C3Yba6027382 for ; Thu, 12 Jun 2025 09:57:21 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.63]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474cd95bnx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:20 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GaMo3hfVWYuobd5ftBC+5qMEMclY+MfKiF9qu21cZIErSJn2OIse5gpSRxQZTCAxCLaaV5nZpWVZphxTmdNOkoJluAG3RcNDxuyw9WBqVFGoJSj2uXZUO2mKRxT09G7A86zNtu4RQ+/dbub4JHrshUO8Qat3qWhHhWEOiXTg/OS1t9VwLBCN64wKhjTyoypMhVPBjKOkP6KnzwKCsgU1ryDb9i/GIQGz9DbBH54JNj8qZxBaZPtw+EMlOJvePXuRhhBeeZY3ke+F5T/uA2j6lxVIjsWbL1VW6d/DhmUqf2pilLll8evPokoMB5FaaI1Vz1hWxqyEUTdhXINfQ9Jdpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iCv61G1SZ7xdpXQnP4cG+SdnI7pJv09C3Rf2iaNyQsE=; b=ms9groryzBXG7AiVVzbvif6/8muSLbZKjLGoLO50VUXiTDXXH3mdYeGDiYszApf7O15/Jpsdb0hmqEI86eIozh2r+LN7YhprkaP6uiq7QJVl3yzwnjgxf6vNpn4VvxbiutLVHdL5Nwf4sDXmKjqQlJtkQb2pjCxS9w6iUEPraGUQH+z9xgpIlgPJzNgwecKgKWv/Zf26F3KBsDag4w8vBj2haCWwNEjunmMX1oZKbAX1PbTME5fE5paWaJ9wkZ+ZqqVWvKMH1gHmPPWvAuBHaQAOHnjILBUy9qC/ssQI7dvU5rBwA8qSx/oFWRrQCKrcErR9j9gkIQLOLWK+SzyoVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:19 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:18 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 2/8] nptl: Update comments and indentation for new condvar implementation Date: Thu, 12 Jun 2025 02:56:33 -0700 Message-ID: <20250612095639.3630518-3-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: c858aa9c-c376-482d-b3fa-08dda99784a7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: VLaC1Ttm2uRWndFhWv8UYxMzFgWhUMDCa2JOmemNICQnRU895G46UjrAqbQxbTphJR5v/Ze2Cfoz45e/YPHid48Tub8WOKROlkEVf3wX9XobHsEGm15AXtJWfn6gl8cyInCz/qIOoPL1p74g0Plkxi7e0MIZTbFUVaDZ62FeV2epnHXEQKM73bLWiRR3+gg1+GEkmt7GLRa7X2BSv0ctM5YvBySyOKbJZxjwrvF7oG5tIQJ3uPdHKqTJy2SM8UYtumFXNLldgnTbBcdhLrQgUPqDMtvVhSlWLV5coL/nTou6h2jh9VJ7dZsnSyPWafD+Ws/imLQQ+Mj/+v2n0qRkmvnQRWn6VwJAkaB1k/lXHSq9pE8rXQ5QC3Dt7cobJrSnUN6KpuAlynnM2c7cX1/aW8ZI0ZUvv2lKscOSVQQq91teUUG+XHLDRsJpXP8v1F7w+23+rzN5nGA7d686iZ7MviJo9K6VvwsYTFimEYhHF/vajvb3Td8kcFJVB+Q7kwEjfEj1WGPZYp2h16CPsW094JwL527aX0KOAxyb4DJcwUvRjbFXPAbooVpHNrv/BWXfHyeFEWbQJl44H2xBUjA3CI6K7GB8CO6szKWBwvVWMvqsjEZPNS3v9ydgpb/zmWURMNgmctEXD9eqrNyeNhbNERWjnsEC89hsDlAP8TYOvOh3SSgxDs3Muwi3y+MeuVwp0y+1iZRbq5Fiv/lzoSjYGA8KIWViyBc5Q1gTlFgZFfpFT1HjQkOJeiPHVxkw5VbPCXMDWP8DuHE+5e97nCmEEfkb+lwWxvjZtYFMtLy/e0Yi7cosYHm1qCI+tYwCndWr6v+zYgDRHuN/+P3XyLH2QcMDQt4hZ181Hzskl5rBm7Zq3POo4AE1vYtt7qcTL810n7Hz73lnvmt1V8TC2lxhVe9O+sqcbcaWQqSPvJz/JIUK0NvENw+wHa3xXMRGw1d5Xyeu9FUfQe6zNTUUe+lLLGftOZrqRe71Ycu0YJgZkHZNpvT6vLnLm4P7fglw2izGnWkycf0EAeWmvDuU4tMo0LSigk6oGycxIlxol+cy60c2W8B620J7beRAm0T+QoINl0TVoGemNwSVw3FsL+XdrWIpyKTTKk5i2btTe9HceSEVcUEJnCPxdUPJo1JLsLoMnNolg2goZpe6II9rUPB7uEQQZhnVUhYuSMMUVKOtfkbXypN3n1k0Cq3caTCutCp4AaGRQTPkCtYJzKuEu7Z08Xd4J1ixnPLfkzI1VJV9xFI7RA/EARPytKfV1ANwmZifYYprtYylma+NAyzst7KunSrNJbCUpxiWHowzd3Dvdo4nAosHpaBB3Yp05ujbGC3tySaDEGdO/ZOs1Zn0iTn419ui4zK5tB3+0yE/5qB2uVhFUImLbw1zSADv/kama7z8uP2ECPTSTbEttIn3TFIfj2Zs6QCJDkybutdvWQ+HMuRjEHF0KGqvgfLZhmBq0YFqfD6NtmgYCBdrf5j9ZWmfpWGCk6ZB+G5itSfFlZCWMwo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 1irmqbI7aR800O5/zV8eSnSsj9fisXFceKcpvEBAXaNrJz3SrZD1h7prnyKJo0/aBdqu4LKSTnIdJ25JVaNwnMIOWrvi7EMxa5wqzAJa5g05nCn3aqUbt3qm3iKlCF0uG7lvUe7x+U2HBz1vd6uCHn9QZkxg5t4l83qf62YubELLBMW5E7AILcSmKOCvchYocO5jEKExeeEXqwN8ue7JRP5WvLaLmYmPEU9ZLS82zjOJyEHG2GtuCSkRf+GJR/N9nQ4fEokJ9Y+ZyO1ZtMRxhclzc8mJEnJp5f1NvnMT0yUOdk9yuFuKW4KqxTimPK/VAz7lcRwUD8elAET8ictoIK9Pvl36pt/iF0G/+nQTZnqX7EaLHCtIhbZ+JSojkHP25DDLW/1SBfDp7oGmWceeuOeQIjeJuAaH3QjqreGEZHUtQYge5FJL19bbWiVZa+mXUJFlUcdNZw7RFlR36oKJanQVi/5NHfIUdDJD9+GVWNr2x2wkrq+7WYxMJZlNQR5RoMc8o+NOwiqoVEt/ebN2xGSNQcNMcaNHBiHogBf3DdnHQB6wZohlpLym4WAqQvgrLBRDlQLkKEhE+rtYDyMUNec8LMfi8xX6xT4Iwd91dUbOL/98qNsUzE7lFnwfyI6P1zD8udFj1igjL94md/UEX1yhbww9A79z2zXJp735fW/GK+s8xba3jmK1DP5kmWRdbmaRzM8Mte30wI1deypYkeYgV2aFENBGYX5KpCkC1fTRWyZBPkzhBhl3NdXuNwbn4ESBRxOzW2C2XJ5fj9C54mkqv41o/09IRfYbu2z2qTurFeJSWADDbFGzYdHU3SMzVRJ3G4hRv5xI80sQ6oGH+zeywnmaTnyMax4YCHu+OkCrQUGRD7hzFMvgILpOf105NAHielKyoxAVql8n8Kb/9IW52n7yA2kFX6yIC5yoiGs/oVc+lTq6S57pVTcHYolfSfuG2s2ZhRHc53l25baZKU9j2tgz+fEiiJn2LuF3ZAYDcjpYe0FheH5kTl/UlELHBrXmJkAQNh4taY8zyMFeI83xS4VUNIsCxcSwbRSQEASsVwZ0AQpffHQ2hEtTkQhZzhWRGRdFenYZrCzJzP6betyWYy8wWqfycJQfiJqa+JZG6i/PRr8izEmHbkOShwbwo1pqybuakUz3UZbgHYxZNiu615fCQG/rNkzl77A7ZQIbPPv6n4EoKwrWwd1fENDVLTPby6v98HZfI25aMfCCOH6RngOvj4hQVn9nsAY2mP4fBlg35ljLBzEAiYejkAEUizwemRqfPT7Zi6802CPBpNP41xf8F7WyYJyhh2LjR1YNkv69doXJgDh7aJgit+FCS7o+ZoKx2XU1hwjWV2jkwcD6od6rtmPjgDdA7Gz1n1ax8PDe6W35LpleWxFa9npTYmWnV0Pp9r2QNEt5ac2LcyBbH5XAPLJEnvKyph9O95yvGXozEWG192zTeDxVPPOjoNrxb2pn5GCwLgEkQhmNJfFeG28t6vEIBePZI0fvfJUdeP8HgnXen5GKIx6vWH+juGiL8VdpNqXpBOKEHGMtdLXNGFRDXktDzShvxZI8n8TwIAzZUf+Rn352lfr9OVi9HJwJ9+a0TaCBXADCiByogQi2nbJt5jzBk7uGsWkxA/M= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: c858aa9c-c376-482d-b3fa-08dda99784a7 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:18.8971 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pycI4Re0ATujlIn7IeZVr/gEHsTWenqpT814RJXJXUA3etPS7u6UW3dmaTGuGiwSvTApud/EYbzmQNq/rizlXhfx+WpQaZFyt8Rt+K9Or0c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=f+xIBPyM c=1 sm=1 tr=0 ts=684aa480 cx=c_pps a=oHfdRNjjH91Dx1UII95wnA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=uzjaQC1v_Til1Q9DAxIA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfX+HpI4wrgfDHB spfWwibp60B8JTH1voGn7PyOzpMbnsq6nyNlnPhfQdV9zSc/HLZPP2EzPPGUefnE7R0HbokYOCg XKSYPFCcxngU6pKJQv0Mc+kx/mcOir8x8GHkJeZExhMi7TnCdIzolRJchnw8LXVEBYQ1R5FCoHU nAm6QC5vsjCEXGmu6qUFA4HgVMbCOv0yj5JZ2cct0zaH+q5SsbhcGwfIztm/G1U2evBnqzLy49n zo3uNAXb/GiOSIbCF9uklslBue5Y8G2VO+KL32NtFjGefbNCKFKoTwybmD1CmHmBuo6z7SZz8af BfXsBA2/YsHcw3sPwTQgakx+vYkb+EEcFIpJA0IKCoheNT/7SNIJpa19jMnXKJb7XeeaftbP0Kc e5vRIIuHTPkE8DCnTsercWyHAaQrfJtRL73ko8qK+x198njGGqC4egP3x5HbIiYXl6p7OV9m X-Proofpoint-ORIG-GUID: tIvcl1a-HWPFOfZSqf5_oEXz0CuDQqSg X-Proofpoint-GUID: tIvcl1a-HWPFOfZSqf5_oEXz0CuDQqSg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:23 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218494 From: Sunil Dora The following commits have been cherry-picked from the master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [0cc973160c23bb67f895bc887dd6942d29f8fee3] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-2.patch | 143 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 144 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-2.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-2.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-2.patch new file mode 100644 index 0000000000..02f41bf3f3 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-2.patch @@ -0,0 +1,143 @@ +From c257ad8c6d1bb4e0e28a5b41035ee9c4e0286ed3 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 9 Jun 2025 02:58:25 -0700 +Subject: [PATCH] nptl: Update comments and indentation for new condvar + implementation + +Some comments were wrong after the most recent commit. This fixes that. +Also fixing indentation where it was using spaces instead of tabs. + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [0cc973160c23bb67f895bc887dd6942d29f8fee3] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_common.c | 5 +++-- + nptl/pthread_cond_wait.c | 39 +++++++++++++++++++------------------- + 2 files changed, 22 insertions(+), 22 deletions(-) + +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index a55eee3e..350a16fa 100644 +--- a/nptl/pthread_cond_common.c ++++ b/nptl/pthread_cond_common.c +@@ -221,8 +221,9 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + * New waiters arriving concurrently with the group switching will all go + into G2 until we atomically make the switch. Waiters existing in G2 + are not affected. +- * Waiters in G1 will be closed out immediately by the advancing of +- __g_signals to the next "lowseq" (low 31 bits of the new g1_start), ++ * Waiters in G1 have already received a signal and been woken. If they ++ haven't woken yet, they will be closed out immediately by the advancing ++ of __g_signals to the next "lowseq" (low 31 bits of the new g1_start), + which will prevent waiters from blocking using a futex on + __g_signals since it provides enough signals for all possible + remaining waiters. As a result, they can each consume a signal +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index 1cb3dbf7..cee19687 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -249,7 +249,7 @@ __condvar_cleanup_waiting (void *arg) + figure out whether they are in a group that has already been completely + signaled (i.e., if the current G1 starts at a later position that the + waiter's position). Waiters cannot determine whether they are currently +- in G2 or G1 -- but they do not have too because all they are interested in ++ in G2 or G1 -- but they do not have to because all they are interested in + is whether there are available signals, and they always start in G2 (whose + group slot they know because of the bit in the waiter sequence. Signalers + will simply fill the right group until it is completely signaled and can +@@ -412,7 +412,7 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + } + + /* Now wait until a signal is available in our group or it is closed. +- Acquire MO so that if we observe a value of zero written after group ++ Acquire MO so that if we observe (signals == lowseq) after group + switching in __condvar_quiesce_and_switch_g1, we synchronize with that + store and will see the prior update of __g1_start done while switching + groups too. */ +@@ -422,8 +422,8 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + { + while (1) + { +- uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); +- unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; ++ uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); ++ unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + + /* Spin-wait first. + Note that spinning first without checking whether a timeout +@@ -447,21 +447,21 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + + /* Reload signals. See above for MO. */ + signals = atomic_load_acquire (cond->__data.__g_signals + g); +- g1_start = __condvar_load_g1_start_relaxed (cond); +- lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; ++ g1_start = __condvar_load_g1_start_relaxed (cond); ++ lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + spin--; + } + +- if (seq < (g1_start >> 1)) ++ if (seq < (g1_start >> 1)) + { +- /* If the group is closed already, ++ /* If the group is closed already, + then this waiter originally had enough extra signals to + consume, up until the time its group was closed. */ + goto done; +- } ++ } + + /* If there is an available signal, don't block. +- If __g1_start has advanced at all, then we must be in G1 ++ If __g1_start has advanced at all, then we must be in G1 + by now, perhaps in the process of switching back to an older + G2, but in either case we're allowed to consume the available + signal and should not block anymore. */ +@@ -483,22 +483,23 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + sequence. */ + atomic_fetch_add_acquire (cond->__data.__g_refs + g, 2); + signals = atomic_load_acquire (cond->__data.__g_signals + g); +- g1_start = __condvar_load_g1_start_relaxed (cond); +- lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; ++ g1_start = __condvar_load_g1_start_relaxed (cond); ++ lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + +- if (seq < (g1_start >> 1)) ++ if (seq < (g1_start >> 1)) + { +- /* group is closed already, so don't block */ ++ /* group is closed already, so don't block */ + __condvar_dec_grefs (cond, g, private); + goto done; + } + + if ((int)(signals - lowseq) >= 2) + { +- /* a signal showed up or G1/G2 switched after we grabbed the refcount */ ++ /* a signal showed up or G1/G2 switched after we grabbed the ++ refcount */ + __condvar_dec_grefs (cond, g, private); + break; +- } ++ } + + // Now block. + struct _pthread_cleanup_buffer buffer; +@@ -536,10 +537,8 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + if (seq < (__condvar_load_g1_start_relaxed (cond) >> 1)) + goto done; + } +- /* Try to grab a signal. Use acquire MO so that we see an up-to-date value +- of __g1_start below (see spinning above for a similar case). In +- particular, if we steal from a more recent group, we will also see a +- more recent __g1_start below. */ ++ /* Try to grab a signal. See above for MO. (if we do another loop ++ iteration we need to see the correct value of g1_start) */ + while (!atomic_compare_exchange_weak_acquire (cond->__data.__g_signals + g, + &signals, signals - 2)); + +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index 2d23c17a48..b7a9a2e0e3 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -62,6 +62,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0023-timezone-Make-shell-interpreter-overridable-in-tzsel.patch \ file://0024-fix-create-thread-failed-in-unprivileged-process-BZ-.patch \ file://0026-PR25847-1.patch \ + file://0026-PR25847-2.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:34 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64823 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id AAC98C61CE8 for ; Thu, 12 Jun 2025 09:57:23 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web11.9126.1749722242494141264 for ; Thu, 12 Jun 2025 02:57:22 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C3Yba7027382 for ; Thu, 12 Jun 2025 09:57:21 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.63]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474cd95bnx-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:21 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kuDD6m6+sTrosYduZhX3Fz3ZFl9+QHUeOj4M0h00rv+/xj4fm30P07Pa5LW/otUFlk5gE0QlkkKbqN8ZB4YLi/b2Hi7/R6MClAah8tH5TpalqDa80X3L+FXb4hVbWoorGBdpGZKW/i42he9ocHemM4PLsGIxj83wodKMWVi4wWreem1FyXgn1uur0CUwxkkBfiShk73MNmwuYax2xwCdgboZVd0PfSjBBWceL0JmR0yGEmKDV5NqoB8bkr++P+pLV9CrN5zpkVBk6wWc5xOcLVWJawwq6k5VtMlirdfSMNxbCLXYyyMobDsB4SSI4IaP0xIZD51Rm2ViYjwBBW9UPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4LtgcHNUNHSGaWYbbaTl4BFG379HFex+LCKj55pOZu8=; b=p6Ing9LgJKRSnpAo/JruNdqG3nyiagDxBoxyMt2TZGkT7x3cPJTToD9CQ0S/1gp6086MCb3jM7E1RStz7sMXfs9vZWOGlA2gcn4nOwCRQr7jKjFfYPF+dfKKlMAtJ42gwQx1fO3bESrEwejyQKioNv7mfOmZuSz7DKnPsUP1jQIVo1Fi+MMijqSmZ8FcZxTXD62ho4Vat/4bUzGqsbW2m/po6xQUrtAu7bc3tuD0KKgxVt/y96mZuNGjuThwAY3b1K8BHo4/lUvnzkHH9QNBR4DIlkIE9dAqjJB5A7ySB0g8bM0Coju3JxEhIWrmwH04l1/8jZtpfQtpEvtK5PojZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:19 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:19 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 3/8] nptl: Remove unnecessary catch-all-wake in condvar group switch Date: Thu, 12 Jun 2025 02:56:34 -0700 Message-ID: <20250612095639.3630518-4-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: 132c0114-1112-4443-08d7-08dda997850f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: PQXnMMNokzGv5uM4SltYPMRF/BjT31PLYi+o974aQnDBKZrclwuLSptk3Kv2IL2zxFiNza25B1YLMExn70dPjNNz8fDQxDDZWVw7QVmz/QjT0A7tN/pG5ZELq4zqN7c+9nwNsXKmo+Ic9KVNbGJIA4d9P1hG7jNykhiN1j9rHYNwNLRbDW1oLBOB3qQWZC/RTzQZ0PuybX/lq54Ns4YoBombzfidl+1LLXB7TF5UZ6XmbxD0yO9AC4kOouO9evzNyR5HJ6981jprkG6bcwWnFa3/xta66OEvgo8NotDKvD1k9djr3aBu/kVMpSz4R4Fe4skUgfDoZPQr8S4rhDtAtkt9SXX5txGWfIvkA9Hf9M2ilu/XSgnAYbiYZEaV+q55BEsLDfuNsgYqvXUBZye2pKWD7h4z7HeTsnUPgIFEipUUygop+rIxqK4DUZwZnPbOZccqNJvYyf7GAhnn25wiqnITgSNz2o6AzHRVJpeiiya9U+9MWmbv5/PhsTzc59HDeqiYCvIENTn7HE/DWPLA7+JelEoGn8N5uJTdSgSVxiU5tpdiF6sRmSAiE06PGOtn2Xv6LV36xkoM2mojheB69tZqepquTOdQ1wjeOhfXvl0tFl2y4G/oEH6iotvNoAm5eKiULkCR1gpTeFZPu7EFi3XmAMM8QjfhkMudmRzRD7QqJmA7RWIW7EIawIJOT1yCg7kul9gLCiSb865BmWX5DRVGuY2Y+dZT90UicWqrjbtEjDfKu2oSkswsaBaiLui+w3JqZ/vqIgdwWTppsQrWitYAJZABsTU0krtG00sO26dGcwt7mxev+Eul+WqdTDtrgnLLluQceRUVDMcA2YzUsbAhuy/gt06rkIAX556F+fu5sfLzioP208ZddpgxFo9AwOhhV96/83Tua2HthMZomsrJnHiEGbMHhJVpqXCR7Vdbxcgh/1KO7OzTHQzQ0HGKlc7DpB93pVb/rS8YIXk01x32f+KVA9Hmle2KJQ68sIg5cn9TOj/DUlPP1tlX6ywtZzSjuTKJa6fKyVw0weUnWgDFHMGrNJxquGtRLP2iLURQO8N7NPv/pVJC3lcKCJw7T72x9wAqn4BSYsbN++aZMpepGARg8UQshsrjcoo0O/eNjf7bdpfDw5fOKZ+Cgn1+CZbn5zm8ixebNiCzE6GIitmPIXKapNxlE42iN5NT3jF/Wo6gyuJ9yo0TGZnFgw1nJM4PTntqc8lIAZH9cTKBwNjZGt8UzVCtV0am5EbD2MUxQyRxB83rZznIbCHTYS4LrkG9xALlNcmeEPXC5K5sqJO5kQXVo1a6OoG3m+dJ/1L0WTNNw9W5hiU5inw8M5LWAWdSkboFJkukieWj50AIx3LKPJIuqvPy+r6FnTnlCWwCkvrsh4iViBdWp/hZj8c3lmnqnAWOujXU6UUmFzFJsifRN3zjwOrrNrSw5dzDy7exYlPVlWSglVdtx8s9YFwf5m6k8KnBis4zfclxaInOfprcvTp0H1/vkypzjGkDjWg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 8KlTu/pmx7rovh8T+SfL2wZo3yNmODwulxUi685dwQuw8Wse9repCpPmvC2TmkItyKSNtGMmPSy09RTNUKEnJnrimnCwqMOurGe/ikDo+JWWn/MyUyXn/GjskB7LT8fa+0yHkJOorbCcUmGzx7oMiCJkN2gkQo7v/xJ1vdF/36vIGs1Yx/UYJy5VS4nu7aEUBofb+dSCaCmwaRk9D2F+tOW6lCrTbbHozNcT8xmSFoUabB+sRqstXBpgfOePlY0uTDWKtn77IOsnjI2i4ECt1oPN/oQWZ6fMDsFFgBFPmOdKSHWNsMOLrNe2ITt8gmpTbCuLWYfmLyhDMLN7a5RAIlexAbrRsb7oSr87AOwRAno55gBJttDDeNoLUX+EngA/d/t6GpOvMcsaw1xdDJr1/6x8v5DIhnByXngSDXSiqrBqYSu3t89v+imjwegDMfF5Sj2Iob53b0K65xQbobevD5ol8b9sJPK05tFxS9FJtmdn84d9hSfw0lpXj5IUrlf9g8VX0yaNvJ23OxEzTmdIwdPHSk/F/9/Seuj4r75Silv8FmotKL/HpUMJkimaT8f+cNxDupo7KshLPB6MntFIKg31tezdKEbhZt6u2CA94gtquStx6GF6KdPHuRCRuFYw4C1Is+stQGU4foC142SJhbNpu+tKay0p257PjR/awAbQMLuCGY4m1DCzAtQ1UHarKKbgu2QsXA/qGHVXPBoduERo8UFknFIquz9biVZxiCVuLzte/RyyKbV/zEuVLKaXYPktyj0M5r48/uB4Z2u2GjqSnlxGsh8HyTd/7mh9MznvdMROeVgtTbgp7/IOMaupmOdjOLAFI2e60QqfA5xni07vq8uXHnOT4tmCw8WoMdJ20xB+Hvfss+DikWj61XzxFgWKNxVy5EVheFv256+aFMgN5tZLKydufHlHM3ANjCuJZdF+wfEeLd4zyS9BUh808VjL4rO+X7w8jMcXl2bR0iYLulFC+T+NQIp7Bezw5SP9xjh5c0Cvj+C3SW0GCA0tUWilCPDlD+AxClAIOYUgJXipu2HSYHBdWxrvx9q5m/l0nfjY/qZIKVFORbYrD732XI74aFd8ZblkVyH2oUwXKYYLXbTA319FopaDeAl9xygLMuU7lcvnY7rbWgA2aOG9LGt8fXAMkWx22RwB7W2oE3BkJRoy1K4duGLfKPNxq8hXmE2pj/gKDKQSmGvFna9ed6DEgUkHILgIU8iHnqii12oyx1sEYaD1P9HPQ9rbncor0A0mIdAXRBGDlxGHTEaPobfFiCBHuzNoJ/AwEiXcoTgHv0rH/h4F3AQiUJfUYfNb43gdo0sNUwDVhD38gsyOBZOsWQeoFvi5QaqR/rak8m1LXOnkJV+uY1yLlHdBO1K5CwKhWNq7KohOSKdKFgT0QM5akotuT4fKbBG3ahFwxQxd4NliWOa8cMFiwuxuYYhd4hvQzqePsYdca1C4Gzy0J+zJb74rlicx2FlJIhJPJoUMA1yon2ftfvDduWoWMJSBZD2W1OP9kQfkSEbRAFQJE9xVkbZuC6QmFBtj6eSrfWCdwgBzh60rUusvhBGfT/TvBbXLrX09Fj4fut8rfNkJcsZF0yMiliQIiOxxUCiBFXZynzwsLCK+ne7abM8X5ok= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 132c0114-1112-4443-08d7-08dda997850f X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:19.5258 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rt0Lfxd3D/VHEVuoRzLZoOExS9wJC8IUW2KqndwygzzUx4pu2/MauFLJsR+Dp525eD0apVAkoGe/Lni0pnC7Jn1eT431ma9oOEh8+Ce/TJg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=f+xIBPyM c=1 sm=1 tr=0 ts=684aa481 cx=c_pps a=oHfdRNjjH91Dx1UII95wnA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=OTrzE_FXVTYtTbWwAisA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfX3bXfvVR4iVNV H6N7O0r9cJNUOOrLb1iozUELMgg44XeZtplSP31KIljj6HSHaIBzjhDUGh6pe78f91PkfOApNLf 4XG7r2t003MAw80t89ynvpNqGf+5WSi1XUZ5jt42+kLLMRl+fefIdpEMSGwFYlORLyyjt+2XSmG JXLI//Movc8S1oFxyZZ97PDo8dIHS8IO5XToi0BoE2LhUx2dXSMmXZCXeUvkxKCNpRqYzCsEyxf Q2b7YrK8bTtH6x8z3Q+kvjcDYLTkXGuAiEs2BjwyOFtuQQr6L0PNlJWOFVwO06V2vsYO3ROInja 5LZu8owpAhTKNMPac703KZGXCh7MkfR3UM+fdF+ZhRKezT2Xl/I6q8xoL2Q2hHnCxtXGS4Xkmt6 1VyqJTLuBt0eRrpcPZdGEZTSv0j1H+kSRaflwaGSI80GlC567XvorGyNvUbTqUHejKINlEly X-Proofpoint-ORIG-GUID: 9X1lFHPtQBDDCs30__xMkQ_GAbWjFGok X-Proofpoint-GUID: 9X1lFHPtQBDDCs30__xMkQ_GAbWjFGok X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:23 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218495 From: Sunil Dora The following commits have been cherry-picked from the Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [b42cc6af11062c260c7dfa91f1c89891366fed3e] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-3.patch | 77 +++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 78 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-3.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-3.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-3.patch new file mode 100644 index 0000000000..566e9f1ae7 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-3.patch @@ -0,0 +1,77 @@ +From 5a20b546d5bb674334b0e658ecefd69e22fe8c90 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 9 Jun 2025 03:27:47 -0700 +Subject: [PATCH] nptl: Remove unnecessary catch-all-wake in condvar group + switch + +This wake is unnecessary. We only switch groups after every sleeper in a group +has been woken. Sure, they may take a while to actually wake up and may still +hold a reference, but waking them a second time doesn't speed that up. Instead +this just makes the code more complicated and may hide problems. + +In particular this safety wake wouldn't even have helped with the bug that was +fixed by Barrus' patch: The bug there was that pthread_cond_signal would not +switch g1 when it should, so we wouldn't even have entered this code path. + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [b42cc6af11062c260c7dfa91f1c89891366fed3e] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_common.c | 31 +------------------------------ + 1 file changed, 1 insertion(+), 30 deletions(-) + +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index 350a16fa..f976a533 100644 +--- a/nptl/pthread_cond_common.c ++++ b/nptl/pthread_cond_common.c +@@ -221,13 +221,7 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + * New waiters arriving concurrently with the group switching will all go + into G2 until we atomically make the switch. Waiters existing in G2 + are not affected. +- * Waiters in G1 have already received a signal and been woken. If they +- haven't woken yet, they will be closed out immediately by the advancing +- of __g_signals to the next "lowseq" (low 31 bits of the new g1_start), +- which will prevent waiters from blocking using a futex on +- __g_signals since it provides enough signals for all possible +- remaining waiters. As a result, they can each consume a signal +- and they will eventually remove their group reference. */ ++ * Waiters in G1 have already received a signal and been woken. */ + + /* Update __g1_start, which finishes closing this group. The value we add + will never be negative because old_orig_size can only be zero when we +@@ -240,29 +234,6 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + + unsigned int lowseq = ((old_g1_start + old_orig_size) << 1) & ~1U; + +- /* If any waiters still hold group references (and thus could be blocked), +- then wake them all up now and prevent any running ones from blocking. +- This is effectively a catch-all for any possible current or future +- bugs that can allow the group size to reach 0 before all G1 waiters +- have been awakened or at least given signals to consume, or any +- other case that can leave blocked (or about to block) older waiters.. */ +- if ((atomic_fetch_or_release (cond->__data.__g_refs + g1, 0) >> 1) > 0) +- { +- /* First advance signals to the end of the group (i.e. enough signals +- for the entire G1 group) to ensure that waiters which have not +- yet blocked in the futex will not block. +- Note that in the vast majority of cases, this should never +- actually be necessary, since __g_signals will have enough +- signals for the remaining g_refs waiters. As an optimization, +- we could check this first before proceeding, although that +- could still leave the potential for futex lost wakeup bugs +- if the signal count was non-zero but the futex wakeup +- was somehow lost. */ +- atomic_store_release (cond->__data.__g_signals + g1, lowseq); +- +- futex_wake (cond->__data.__g_signals + g1, INT_MAX, private); +- } +- + /* At this point, the old G1 is now a valid new G2 (but not in use yet). + No old waiter can neither grab a signal nor acquire a reference without + noticing that __g1_start is larger. +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index b7a9a2e0e3..d9073b6d64 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -63,6 +63,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0024-fix-create-thread-failed-in-unprivileged-process-BZ-.patch \ file://0026-PR25847-1.patch \ file://0026-PR25847-2.patch \ + file://0026-PR25847-3.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:35 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64824 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB054C71143 for ; Thu, 12 Jun 2025 09:57:23 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web11.9127.1749722243054110359 for ; Thu, 12 Jun 2025 02:57:23 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C3Yba8027382 for ; Thu, 12 Jun 2025 09:57:22 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.63]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474cd95bnx-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:22 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yagfpTr/4gnTJcV7aP+yTYOO/jplJqkDpYGOUFIw2oETwj/nkWS098ejpuRlOhuLJbzhOEqV2/ZR55yytjGs2h1PI6+GUDk1nBv7UUtu2KigYjSzBJe3EispAv9w7CjMF/U80ZPXInCZPwWDFfGL2GkmPHL46Ws4DmQy3ZUf+kNjbDNOlZP7Y98UDfgQa5AFHUKYhX9K8EOCF1b4xHVlAkKPvS2Vx/mxH56hXZyxAPgQIzPx6KyrTS5EeiDzr58Yzb5eMjFRUPchkj11mW7iNbXheKs5DMpfIq0rbbNEP6OyRbSvBcJHyfiDNvR2k3Xk+9z6ng9ut8oWx1bbnwFMKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6HK5qCswRsv/UjzLXYVWUacDw8dmSGwIVKuC4cuFycU=; b=ya6/HI0OcbagI/N9rsGhhzB7WOlvpKmBnRV9t+/gEvqtvtrp5Pdfzu9nG/d5kT4OmixIDyU3snHcSksxVskhiUA2hizGqFjX7Eqr312pXMbNscfGtV8yBpDhKSSukCp8m/t6Gr3MrZ6hP8TAee/6LJi9/E0HGQSBSzZq+hY12NCsG9m4Xu/VBZoT+sDo4GdWO1XTAthhMWHxEsY26Ngfd+a1nIvmnfzCEYoDT1zf6AyhP22+f2voOvl/LY5lxzYuo+tQsEp+ReUXwD4Uae6+cFMyYxB+xBJZdcyVc7OfFVYM4pr9/gJ1X853+uXr090OpT/H0sP0b7am8a7d1cnqjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:20 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:20 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 4/8] nptl: Remove unnecessary quadruple check in pthread_cond_wait Date: Thu, 12 Jun 2025 02:56:35 -0700 Message-ID: <20250612095639.3630518-5-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: 6808f9e0-7837-4295-024b-08dda9978577 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: hrOzNBqj1wzauzQhUv5ubMNsWkzVFbieQA2T9P802qIKQRmj6xY0NGRJ0e/E428fucdpRzoeJKJetA9L/Z03DHDFAflYlc6NyxcdPpkeDaKYQunFoVY7/JhTcN8tawkhD5AB0vrWMghhjKRHHFGvWRtoCDMZH+U7LQL/2MqmjfcNHyqwmHvS/Ivz5I2gzCewuSWTEUYyxj/RppvHLLiz6T7t+9QImcF5douj/PnD8K+GcUnIWuuQtuyZ1Uizmo6IgnQMaVLfygDKv7oDGAg5ZoHyNsrpP1JfL/NpZKMzALvtcVNWglb3NPB2UJ3uGH9c40Xontofqm68kCJOy1mYaJBgLMcEkuh5C3onT1XJzoFHgXsdYMK8lQzODWc6rwkTl4ZMl3LjqIMKQRlWkhcbMWnxu/kmDkbJUaXRh3t+wQ27SwYgmBZU/mpiKDQVmrZ0aa7ToFJsKAAsYt3xHFw7BGjKNeNNHklfupdGhTdeBmYBCQ09fJc6lWs3j1bRDQ2rWVpz1T81d3+dsyMyWSo6ivLcGVs2iomponZhP6xA9hEY//cssFUMlozVCNMorNJam5i/U+qmEnPmqz6p1WgebF1jpu0UdLg6YGx0b0ZNJGp2zaDA4tAZK9b0V06+B57kwETwofxzaYS1oK+d3AuPGXfUcrPUlcjS8HYRlZ7ASUtPpzncCoRoOVZgbVHuzX8CnwoSY1pm2CASD0SvxJg8jnqT3GRsknfmFfvXstz86MfNLwCaoEDX6rwMNznAqaw2/XJR0qtnRUD1+/o5MvT9kpScehCS9JqYEJOTK3HsITTLGMTNXMl3qIAbOeGosYs53OxVYbpAEWojGZeXki9xOEO0U44s27b0UlYqkQ/jdzdaZq034+3mTVQLT29h5NTgZR8suEkvOi2IxT2tOoDRCOEm9m07eKu3+vy8zTd2+c1h4W2zArSSbIj01iOSscSgVsz3u8nmeUfo87AObb05aw76liYoU4hyCN0+xrjJg+jPGVLic8ggoBPvcG/xSKiKxxQNXtn9dD0ghP/o7fDTAO5wY52cPrnyNUI/zgaQ5LOYVgnrz17kQ28pTi9Kmtctyi4AwGx2E9VECeENqsiYG3bKFVeB9Spov6RN1OhJ3boRPbVIWFCVNsTN2G/CJK7+7X4/09L8leT9tjFspsHLg8EHfuYlxZhn8V1zwr70KDt3t5RkN15ZThcQsSWJFoP0/L6XtCYeMU5Dj3F7Vr3lKnoaC+BXYxk8qFitK8OmSRdkayxrtmmjC4KRU8Qbp+UslXkkKB+/6/NNdDiJMvQJ7JqTuCvhz8WnUZhbP19ytKVVupMEjFsZhnbH8CvFyJIwwRNpTD60PzS7sVx5Sx0KRdl1l1nR4tOABRIH1kI/f/tnMMcQKrvHR2GRgI3q32ERejo0FQN0El4XmI0a+nIsgjfNaUPmCNdlW/VRQqTuLzzdvWjVa6KWK8QEcRopIxq251fpCgT2hoI4U5OznV+e6UPPPbEBySLSZXLg3c/fYvg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EJ3mLKzku2YV3nSLP0gZQhZdS29q+bA+bjRPOP/IEBz0hR6GkrZ54a3iWJVWXEOtyaQ4PN2VHB9k5QnyDv5whst7w8fZJLyfvI0QupcopFzC83L7Hfwh1nj6cC4o3wAISVHdBjWzehZyiSYtHRbcEwcDDU5i7QSDwkTJFsAAqu7SnGQylQ5LKItcY7aQ2jf9Az/GPllsluE0h7IMpisEdHSPvbcoQTYj4OQSGejJbgxa5Cie7K9l+Y4Nm764kTxr88M+gG1FFGVeJ2R2/Z30wFpl3DK22XG/aLjx7ObKxRAV5cB/Xpxy/5AdfORaHYb3kcOlWUmLVTfsMyCXWKgxfjnGkrqs9LT11QveVPOTWzF05J3ZKMPCBKZ++DHY5DAf3kWaBoOP749QN6dWlORj0T6QmHO6nWL1LecaR66XvlpFlgXn17FY353mwpKUVao49+8+u3yOxrxTArP4nfdRlssFkXTjePloiN03LPF0TpApf/p97PMk+aSksw9zkgY9Io497yfizifZ0qo0Jz/VOFFHE9BCeNehtfqKWUYglu30WhCDV6UG9iCvhHDntkzA2RCzHjqnswb6EOMefyHBJqupYSG4EqBxig7Or8GH36eX3srncb7iH619QH6ZT+ezKT2uJHAkxqGf461hwh548aoVwkPZFEhKjmbfxCEK8lQkfcUJIH9Q4BpomRfo8IrXxjL4aIRadE4UfPEf4R0ETAZnQdja3RknLudlNjywUttuBJauhAo+VYPZvlEAb621xa0ZFrQuJGjxqi2/37ru8RjCaus5ojRWneuwsaDSjy5n+ZtDWCcFM7f/u8Pz+9Rc07pJEbX02F2naQ5dd2TDKlcxW0w9K+KNKa8GDL9wrBMTFb6i+mRcMOPK4Zo9L7CeaebM2myV3jnmVs/w6ivXbhi9XqquIRZrEsnocdIgfjAo3+Way6RLCG8KsQNKrvxUuE6dvdUdgvTIVe5tVqrnJ52LR9MOX3SfmFhOol31wP3f4dK8RLKIRrbLj1DhkzMU/NPp9DhPODBApms2AjnI64n9Mf58yEJ1cWbd9aTt2uqPq0LqGE9F8uD/5cSqtbRVe2r+D9T66qaqSu7UWnuC1Z90sjQ5JoWAjMsA+x/E4l5Gk2kQ3yZeQX13OKaaLQcsFgp0PQUQF19vb/R7hvpx/7wHubKkBj+K+ZdE5qgLimdxucUaZfnFg6hqGBXeK2hc4xC8dfUSucIrca36tiRPCswlCfGkDlo3qugkzeEIqKkCctyOQFC8ws1Cn9ktiS5njQBPvP8V7epgUgFKrDXkB3MGyAc+i8U2sdDnuQU/22A1mJm/yh79dpf4ix9y5CibMigBHGH52IOHkv+gmceUr4QJan6z+/X3a1n4gLNC5yN/AIriCZXC/ggXPqkuffF6HEKxRgf5dRr10+1xWW7P935l8vVeTQo2iD0djgBNZ6/Y48x5KujvcU6g7cpT00KG6Xp0qeDaWsxEAVndz595zY4l1xN9o4kwG/XprKwBMbQ5uRAUZ01Icdk76USIifbql4JvVyaqKtz8N1tzAu+a7WILGAvR5BE1otKi3vDeVhAYl3H5dcLUkDIfaIoMQ3hH7OwDi6KCsZCHaMfTuDn/fuzrolBArkji/PT7e4ME4H0= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6808f9e0-7837-4295-024b-08dda9978577 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:20.4053 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CSnceAJToxGADOrIvuzq2H8uqHbsXd1QmwT8fMjSl8wFHuoyHphapCRl0z+bHGqjz0s1rsOvSZf/KHFhYVEfartRRJe5zxrboswOjome3nw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=f+xIBPyM c=1 sm=1 tr=0 ts=684aa482 cx=c_pps a=oHfdRNjjH91Dx1UII95wnA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=NpP8qUlCxzQSevXvkUwA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfX1KY81bbtuoea tOAvhhLniWCoAg45gIjo5dvsOj53Bk03A16iEuXMPO/5QLKEYJZesoP3KDL55eezTm5wouTDFC5 czhlnR6GDyIRwxv4JLwJ0bd8KSZIJ903yrxJYMemQ7JtKqJsbIeXCRfuNix1dHfBRbCveAzlYBu 3lJ7b4K5ANb9EMsuvp+2rOrfcZSH3yMMfwKW4TKjnbtRQQtdM1G+YED/moyhX0aNHTWWCjQA/S+ QdtnRtPdunX4GCVE0Kes9zNYYLFbcVFNmQbkkyvcPldd8GMRso73ffGZjZifHLX2Rrm6ecwoT0C OSlgm6VC3dRyyXsmr1c1S3SV3c32+/wi+IZ5V66y+a76Jn0fzkqcbMjhsgmnDDrAsEyGCqFPBUV a+z+sA2FXmRp3iaiIyMLDFkC4+lRYt0OzQQmVOvVYwOdU6RaXhqrDtFgWXRSZ0QjmiWq3Xuo X-Proofpoint-ORIG-GUID: kLoVqFBxaRKzwmpkNP4oxVIJSTzjqI2_ X-Proofpoint-GUID: kLoVqFBxaRKzwmpkNP4oxVIJSTzjqI2_ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:23 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218496 From: Sunil Dora The following commits have been cherry-picked from the Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [4f7b051f8ee3feff1b53b27a906f245afaa9cee1] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-4.patch | 116 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 117 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-4.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-4.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-4.patch new file mode 100644 index 0000000000..11b2f6af2c --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-4.patch @@ -0,0 +1,116 @@ +From ba2090ae4902f910024309f8203a228a756fb289 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 9 Jun 2025 03:40:26 -0700 +Subject: [PATCH] nptl: Remove unnecessary quadruple check in pthread_cond_wait + +pthread_cond_wait was checking whether it was in a closed group no less than +four times. Checking once is enough. Here are the four checks: + +1. While spin-waiting. This was dead code: maxspin is set to 0 and has been + for years. +2. Before deciding to go to sleep, and before incrementing grefs: I kept this +3. After incrementing grefs. There is no reason to think that the group would + close while we do an atomic increment. Obviously it could close at any + point, but that doesn't mean we have to recheck after every step. This + check was equally good as check 2, except it has to do more work. +4. When we find ourselves in a group that has a signal. We only get here after + we check that we're not in a closed group. There is no need to check again. + The check would only have helped in cases where the compare_exchange in the + next line would also have failed. Relying on the compare_exchange is fine. + +Removing the duplicate checks clarifies the code. + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [4f7b051f8ee3feff1b53b27a906f245afaa9cee1] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_wait.c | 49 ---------------------------------------- + 1 file changed, 49 deletions(-) + +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index cee19687..47e834ca 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -366,7 +366,6 @@ static __always_inline int + __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + clockid_t clockid, const struct __timespec64 *abstime) + { +- const int maxspin = 0; + int err; + int result = 0; + +@@ -425,33 +424,6 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); + unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + +- /* Spin-wait first. +- Note that spinning first without checking whether a timeout +- passed might lead to what looks like a spurious wake-up even +- though we should return ETIMEDOUT (e.g., if the caller provides +- an absolute timeout that is clearly in the past). However, +- (1) spurious wake-ups are allowed, (2) it seems unlikely that a +- user will (ab)use pthread_cond_wait as a check for whether a +- point in time is in the past, and (3) spinning first without +- having to compare against the current time seems to be the right +- choice from a performance perspective for most use cases. */ +- unsigned int spin = maxspin; +- while (spin > 0 && ((int)(signals - lowseq) < 2)) +- { +- /* Check that we are not spinning on a group that's already +- closed. */ +- if (seq < (g1_start >> 1)) +- break; +- +- /* TODO Back off. */ +- +- /* Reload signals. See above for MO. */ +- signals = atomic_load_acquire (cond->__data.__g_signals + g); +- g1_start = __condvar_load_g1_start_relaxed (cond); +- lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; +- spin--; +- } +- + if (seq < (g1_start >> 1)) + { + /* If the group is closed already, +@@ -482,24 +454,6 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + an atomic read-modify-write operation and thus extend the release + sequence. */ + atomic_fetch_add_acquire (cond->__data.__g_refs + g, 2); +- signals = atomic_load_acquire (cond->__data.__g_signals + g); +- g1_start = __condvar_load_g1_start_relaxed (cond); +- lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; +- +- if (seq < (g1_start >> 1)) +- { +- /* group is closed already, so don't block */ +- __condvar_dec_grefs (cond, g, private); +- goto done; +- } +- +- if ((int)(signals - lowseq) >= 2) +- { +- /* a signal showed up or G1/G2 switched after we grabbed the +- refcount */ +- __condvar_dec_grefs (cond, g, private); +- break; +- } + + // Now block. + struct _pthread_cleanup_buffer buffer; +@@ -533,9 +487,6 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + /* Reload signals. See above for MO. */ + signals = atomic_load_acquire (cond->__data.__g_signals + g); + } +- +- if (seq < (__condvar_load_g1_start_relaxed (cond) >> 1)) +- goto done; + } + /* Try to grab a signal. See above for MO. (if we do another loop + iteration we need to see the correct value of g1_start) */ +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index d9073b6d64..9aab1466f6 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -64,6 +64,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0026-PR25847-1.patch \ file://0026-PR25847-2.patch \ file://0026-PR25847-3.patch \ + file://0026-PR25847-4.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:36 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64827 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEB86C71136 for ; Thu, 12 Jun 2025 09:57:33 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web10.9249.1749722243594875091 for ; Thu, 12 Jun 2025 02:57:23 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C3Yba9027382 for ; Thu, 12 Jun 2025 09:57:22 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.63]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474cd95bnx-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:22 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=S0A6VRc7LMxjdwjc2LxYgNF9O6IrW5bO5u2arJJmpnr2EOQ0mTqv9i8RI37jzrcA+chUclEsxtIqya3A0lgfqv/Gmj7t8SCJ6P6CbY31agUSVeO4zg01Vr3dM5WQxgXZybAtA6BRme7xExEM6+/WGr5xHWdi1+77NM+XlT+tgxOhgi8MvcolxiBklxBF/jRML4oMqG7RhOXbDeG24VRoxPF4WRq0CTMb0OL846kq3Rrwgwle5zWbrw6OMCZVyhTbljpmdvgKDLcax3ztEt1JIasPaAPfKyiq0XAM4WwxHwOLJZI3FTa/WLeAjbAvJirsG3eHGLL0iDRPrr5QPmxorw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LddEci4mqEhCz85k/mCCtq9cdvUQpY8pYijXwCNkp7M=; b=K0xNnPvWz4I5GD67l9qkAlet8lvISolUtCqC7/Kax02ZbOmpjrNKzPpipXzrF0L9qHOzQCrsuOOUFAtzFL0DlXDujErPjiwn2YfVkys1gdGyy3brrg1GKrS7K+5dVJ7+EFZL4TGvZLR9t1MQuMVyxhA8jvahTFmf4DMvvj6jlnsMTKZfJHeokANdJO+kT+/CIxSeDitvS5pcp3X61hYvNqnw/c/VVkzvowCURKEqW7hapr1ZFJtwP1I7CadgOqpqruna8512sRbQIy+cfLCvFR42AocTwugKXiSK1R2tar7sUv6/rmxErQJQJgGYAuJoNO2ot2p5JwbgxsBpIsJDEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:21 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:21 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 5/8] nptl: Use a single loop in pthread_cond_wait instaed of a nested loop Date: Thu, 12 Jun 2025 02:56:36 -0700 Message-ID: <20250612095639.3630518-6-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: 16e1adcb-60f2-4088-2595-08dda99785fd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: kKceHYpcpI1GZBkU/siLEH4h8DkyuKHbGIjZDT5Vo3dNDYJ3hX+6RWiCEvyQS5BD8JDJcwOluTKtekR2iPQSGPJ9yw2hc+Oa2nppbKUJ4KSe01ZWXCmF/6wOWbX0zcIPRLywjQ+cClQzkkp0iWEhALQ7+Agp+6kHEVJyRyCQUm3tjLJSMoRM2uOyYSZMTGaXb0+SDsC9lbb05dwOTjSLd5XFZ/QnYeYIacV6MKfnSkLUjoYHmyhauebVRQIPY5PwpOQ5IftL95EFTIgLPdZZvxeawwvS+HuwrWdV3sVnPs18eZsiVXiErz1bImjcdQPq1koYsWWOopdRWjDnSumu2bIYsLL9RDlDy8yYySPcczPJOD2SovHvcvs6vqCE2lt6HbpoSOJSR56G/g915L/5XWIeeWlINio1krVrDQ9hMnOZrsjtMZBDMYbQBal16tPw8eY0Y8wHu0t4XkLUKUvkwr+763ShPvhFPhnF/U4q/FafKnhtO3sM2zxEcgmb+fsML4a0E8TCiGeIfUlcudJDBjPxITDy2CMeEoe+XGWBQ1+lNrOW6Xzu0IrKrmuBIlcU2kIIcRNcIdaqPzj3UjMwle7fx2C9VRnV809tPHrUNcacNnnu11d2etQPkcT+Ypnv4mRcwy5VQsZIH9uqALrxk5Ga7HT2m8H31C1++QUq29uSKvZYh5vtHlFmVXfjMnw2mIpVFWwu6u4l9ITcp8ShR7C9zGEnrT++3cA6umP+rtv4sAb707ZxkeHjKamhRsOySCx2OKXP9uELHIOuSfDSXSEBboO+m2noL9A+e53xrrqTJuMQ8AKjYWaTqKI1vCjtXwgkMOcKwynTmBi3JOZuXi7689lodBs5incdKb9S9Qa1qYLRyK07F0nNYTyMzpgLoUDVzP9Xmi7da/sBo7MYiSluNpb0ItD5pe8luvmCv/ie5iG8LnTzS2nrKB43oyiYuwryhAm5RIG6QFtCe5dRY24d31ZLy+gBcvL3P/hKGmTzQNvPzMtkcDvNwLnSm2htD3HBXiHjzcshNpeaaG567vWG2DAO1B66PEBzn21ZzGt2pCvFIGUoX893TSq3DItrgZSgxn78uVLVhRqxVLLYBwthlZOwSStGnHsUauBLYu5aLKv5C7s1gah9snwEn0kOXLfX12nnnrSkmmyFaLFA/2z8OoAEZ4zV8h1ZDHwnZmKB/4jbyJTkZLOd1XC03P6oDP6QLodkYgFaKeOFQqb4f1LChk4mBYiTYoJbqV0TOt16zus53E7+u6AzZXN5bKzzbzTXMo8iOpTXjFAoY4ELbhgQT/VrV4JTq+UuzbsHhcH1UEvRtbrPm5Grg2smHjsM+LEvDSW5UZnjoerNEikJB5EwbgXgJDtXsjo5K9YO3DnbrdcZOlqgHvpvViUGayFj5KGCfIodMmUKBYphqnFKscFMwGQIhP5k6E8XA+IVHvoOcbYgmvC3TOrWBjIirkE/aDHkQt37/iHyamlbYfSyJg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: mWDC+GHsHw98XE6zNMHjOxMEVxzY1W72XC4uQ2OyiKM5Ej+cBQ545EwZN1jgiNnJOWYGBi7KulhRMJvNTDrFS0vscfSftSNEAb+zVz8uEXiYtG8SE0iAct/u1K9/HURUOzIZnV5+yYNY7m+CZC4O2YRCM8lPmK3eD26ckkejubV7wJ2WT/14s9T0zihjmC3fw2IBQITpfFMllliLA7KinwsWxTowe/LKtYF2R8YoJOSg8LMluqDBoTHfwBmXrLKbaOPNPWCGx7WggyPfJyuLsrKsFKahVNzag0hpF7THQfbyf02WZXLPo+i/BLuuZTDuQAq/glVcIo/DZk3t57Ju9kX/ri/E06M0JDe417wL9kBt6JXgOOddzp3ZoxR3kUpRRcShjfvn80Ja5QgvnBtbSUDceJvKY8ccY0TKMn7vOyxxMZ4LlHeF8nlFmsb7BLqE40q0mxZS4AHELvs2tbGqJjtplgZyquhn0Ck56wX7M9hEsw38iINJn+WQBSh8+h/F1ryxLOr+01p3vR4YFQkyrTfD1NeROULMmcJmqRorUPsLrHDvhjpj3BcEY0/r/qcbF/2Ni7HvaAeynRyYaI446xUfR2GH14yRka260DvAjDUQVszuRUUa0+5CBNb1bcyA09lWp4vYd6jVjh7U3GJJpTC2iM1LUdAhCs1Y5yAmU51XL/ADgKtb7Xsj+VCUgo1rW/Pl4b9ehjtsRJ5GE8pU4OiB4Yo5GYbhxuzkoOf5cLpqYeZdQwncIRtjLt8KmH0eZz7g30ZZUo5b7sRJ/IT9aXGyBrXpTCFnEM3tFZ+BLKUcs4lEGNmQPvqWZJRH84AWCpgxahJATXAA32dMRLT+tP+YpersBXrXGGmelYveDCQAylenXk+MeT+j1JawXVgyPf5pBISvYO2+t7squEU01JcD01TI3gmGMvDaMkCrpmQiZF7bdJIoCy2m9okJcXZN5Aycj3CtpjysC1Gfx4Se+FOoUnNDPJbXlv2x9BTEsm9mh0/WTFzs11Egx+lhYB5fUcVACdINp0pUX0CX+l18TcTF7ve3MN3PnxNnSsPqR5tkyD7tjhR0MusO6PtbdYKeBlW/8pugJXM228gJHHbzWMM53j6wQEX/AsXYgSU4+gQQ0fnFMDOPEPNPTH9LZ39kSRC4hMQ57leQMN9kAbuDaAkD1zrGp6UwjiBQrDyZ5xufjpmfGe3QiTdpwaq+uBL9K+BcUyVl8khMV5gfcXxWfOxctv0Mucgg0OglWV2pr8mdqr5ImrBh/ZyeVdqYV8PEIJ9w2luBFrZAzMCj+cUSzqpMID8LjBHtO0Q7bv93u3i/cKshj5SAfeO/CHiIQEInPonzm0WdEKKcwYlxPZR2+ncbnbeQn0qKcGlcqbvtcxWbIZKYaZgyqOlTz0lrTEqE3mdKvFw7vZTNdGgXfR4jmjstYhEgQjg+Qbyf/3/LTXIpyjcW+HN/YS0shGSZgzxDNhtYt+oGsTkV5j/IKgWkuKkaaqueVTOmOKuUYDrK/uLn+LPGPesCP2ARfu2WSjx+u2jBqrcTYcp1xErgAd2f+NNuCeRhr6QiVkjwtMzglN1980gQZtge1dYt4QzvG1FnYv0AVBUui0XVkrBjGRfybgtY5MKfR0AwpEg0KE1jN0Q= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16e1adcb-60f2-4088-2595-08dda99785fd X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:21.1059 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nU73Eomdvp+iPB3gEccWnH5NTR6/2JkrcsAEDH8WeT7DxScvAM+WGNn0l4gPDLbB4sws2M0LGzEiaxJfJTAMAOK0zZKB990rFZDg+muPTGg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=f+xIBPyM c=1 sm=1 tr=0 ts=684aa482 cx=c_pps a=oHfdRNjjH91Dx1UII95wnA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=CuBAfw1dTLWtH10FsFEA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfX8uRcdlsghpfV jjXHrsLkr9NoXhrCsDVqxKSgBmaX5vZi7TlOqfvBcfPZObm7lH3Xr/FpG6XysA7yYPygswwTRqe fWzC+0z79IJ2wQHdjSDMjSy9y7bBkFN9pPqP5P1m83U6kB5XcX551DP99cpnnkICuuucv1vkQWJ OhnoI2LcP489LQgS2ZL48O5rxFMpz/cCMJ9fCrRbNOms++eKahFRpLB+cl+p+ExnGL9lyyF/LI3 35g+FI+z32TJmeuoWPrPIlxKMGmJl9h86ML76O+vgqLClVO0s2tJilddknQcoDzoJACw6jVa0pK 51O1Th+okh0ySSMWIM+gFkfvSguUHykka+ltEFqUNObVYJa4xvJ87zbekt3IOTamCH/pTDlymDo KMcNlM1pCftZateSfKvjyt27Nl/4c42AMPbp8iUU/4GqipW3kuYhI7VetXX1RenUNtcvH7PR X-Proofpoint-ORIG-GUID: gvnNeS7_XSCBbAV9jm_diLmLGktPboYg X-Proofpoint-GUID: gvnNeS7_XSCBbAV9jm_diLmLGktPboYg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:33 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218497 From: Sunil Dora The following commits have been cherry-picked from the Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [929a4764ac90382616b6a21f099192b2475da674] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-5.patch | 103 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 104 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-5.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-5.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-5.patch new file mode 100644 index 0000000000..e896fbe2fd --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-5.patch @@ -0,0 +1,103 @@ +From 24662c8d9fcb49cb529cab328df90969b961073b Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 9 Jun 2025 05:32:35 -0700 +Subject: [PATCH] Use a single loop in pthread_cond_wait instaed of a nested + loop + +The loop was a little more complicated than necessary. There was only one +break statement out of the inner loop, and the outer loop was nearly empty. +So just remove the outer loop, moving its code to the one break statement in +the inner loop. This allows us to replace all gotos with break statements. + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [929a4764ac90382616b6a21f099192b2475da674] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_wait.c | 40 +++++++++++++++++++--------------------- + 1 file changed, 19 insertions(+), 21 deletions(-) + +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index 47e834ca..d1714a0c 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -410,17 +410,15 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + return err; + } + +- /* Now wait until a signal is available in our group or it is closed. +- Acquire MO so that if we observe (signals == lowseq) after group +- switching in __condvar_quiesce_and_switch_g1, we synchronize with that +- store and will see the prior update of __g1_start done while switching +- groups too. */ +- unsigned int signals = atomic_load_acquire (cond->__data.__g_signals + g); +- +- do +- { ++ + while (1) + { ++ /* Now wait until a signal is available in our group or it is closed. ++ Acquire MO so that if we observe (signals == lowseq) after group ++ switching in __condvar_quiesce_and_switch_g1, we synchronize with that ++ store and will see the prior update of __g1_start done while switching ++ groups too. */ ++ unsigned int signals = atomic_load_acquire (cond->__data.__g_signals + g); + uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); + unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + +@@ -429,7 +427,7 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + /* If the group is closed already, + then this waiter originally had enough extra signals to + consume, up until the time its group was closed. */ +- goto done; ++ break; + } + + /* If there is an available signal, don't block. +@@ -438,7 +436,16 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + G2, but in either case we're allowed to consume the available + signal and should not block anymore. */ + if ((int)(signals - lowseq) >= 2) +- break; ++ { ++ /* Try to grab a signal. See above for MO. (if we do another loop ++ iteration we need to see the correct value of g1_start) */ ++ if (atomic_compare_exchange_weak_acquire ( ++ cond->__data.__g_signals + g, ++ &signals, signals - 2)) ++ break; ++ else ++ continue; ++ } + + /* No signals available after spinning, so prepare to block. + We first acquire a group reference and use acquire MO for that so +@@ -479,21 +486,12 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + the lock during cancellation is not possible. */ + __condvar_cancel_waiting (cond, seq, g, private); + result = err; +- goto done; ++ break; + } + else + __condvar_dec_grefs (cond, g, private); + +- /* Reload signals. See above for MO. */ +- signals = atomic_load_acquire (cond->__data.__g_signals + g); + } +- } +- /* Try to grab a signal. See above for MO. (if we do another loop +- iteration we need to see the correct value of g1_start) */ +- while (!atomic_compare_exchange_weak_acquire (cond->__data.__g_signals + g, +- &signals, signals - 2)); +- +- done: + + /* Confirm that we have been woken. We do that before acquiring the mutex + to allow for execution of pthread_cond_destroy while having acquired the +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index 9aab1466f6..05f408065f 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -65,6 +65,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0026-PR25847-2.patch \ file://0026-PR25847-3.patch \ file://0026-PR25847-4.patch \ + file://0026-PR25847-5.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64825 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B345EC61CE8 for ; Thu, 12 Jun 2025 09:57:33 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web11.9128.1749722244137385730 for ; Thu, 12 Jun 2025 02:57:24 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C3YbaA027382 for ; Thu, 12 Jun 2025 09:57:23 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.63]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474cd95bnx-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:23 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oFhkyMggBpbWG+4sf8IArLWOzbCrDdK6hFwoC/46gh9ULJyK3X6QO9nz2quJmOv6PXgl3SSwscrn/ktUCUqbEMn4T+1j8JOfmCVWoe8W0y5s19T/Mjdvu79RpYvgOv76+E1MQ0RZr9IAGYgQbUs6EFzpVC3bOOjsSfF7gAh9n3CZP2KmDUKNdCLEE16CRn40/zUuikUEgUC8O/Ld2Q/bKMPYpxA+lrjB/mLrZrPWOymZKaKjP4DNujnODaJf4V/OUDW14ZHiAZrctT02DuxMtOeub8LBue2WpxyIbDiGWFep+4zAynM8XIPYO19pCTDV4+U66ytSCbOM3PYvIRQ3nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k4Lu0EvtzUMiGHx9p+cgGCQ3fOmCplCemIzHEkvp9ww=; b=usLS2KU+FM4oDuf5nxxeL3ymU7u9QQhrI7XYxxfu26AohFJUdsr3uYVDEkwBBzN+gWSTi6JQRL3ELeWCuOhbPKwJpiQeAiOTioKMbbNXZj+14C15tCI8ICQulrwbwV/g4Fk+eOHcBZcWUHUqIItVhfhf/2w2w+7k15X13F13Q0Lw8svTsJULkfPGmz3n3mQFMQCg7i+J7iu+wz3TIhpNivPAK/IbVxCpFBDLELk5E65gJWFEuUls+dJpo1dRrBy9cuBtUlVpBPA77Ud401jmmnjcjPIif6bJCBqm98zUQc/ERWtKuXYD96T7roXXa/Qtfcuu4+rRoDbkubGCdEfdQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:21 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:21 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 6/8] nptl: Fix indentation Date: Thu, 12 Jun 2025 02:56:37 -0700 Message-ID: <20250612095639.3630518-7-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: cd3bf716-b40f-4a42-37a7-08dda9978663 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: GrzzppNDmigYvxvd929JKqLdDuxol5rVgQebsdx+59uh6R38aLhniPuLt/kpQReBd8SuFvpDbYlLqUe/7lklWf5XgMOj5FkWzFm3wrh3bujZvpC0wwpO7yBtdiG0fgp1WOWNsVXjZ51zSFwNNlLDYzyxRw6EkOlX0wmR+VnJCb3a6z1DvDhStW0wk+rlC5f09ULmNnOchvUG8CCY7Q/gatyTz7saPmbZoFO2L2g6BzQxDXOBN2G7LeleE6DPyRNfUHgwWEZZd5DpV939aa7RXL7W6Pnpmb7H5WAsThWBC9tUje0TYmB4saH9qtueVyHaMoZrvIKKp/NvlKYyUO5YaUvxJyL3/Wjvmfc2JSjnkC+VoDZXrU4yeY7L57121ARwBjZengk7uHvJSB6r3YCyoyIvLlCNpFipVCL1xftJBGc/I4JcOxYqaqboWbUmy9lcxZE9PZVLNeWLvO6VJqHweM5VmcW22JTBgpjSt7Hcojp9hPMbpMzvKooGn1KeEZxfAUMalE3ZynVlFWBPyy8UrAmHO+SR8n5UmKM/Zpgo2L76o6PZ+ZGKDg/8/4z1aKD1v4tqY6DacyRXIsO88kLyYoMdQR+CjRgmbzC6gR8xO2AUp9sRiyDXpYhsXLA4iiT9qj4kZB7FoLfxFWPJj8xxfFbsncHaDcobsYUf1/wBFY1J4qoqNqlxiPjklURkIUQiBgGrfDfMF33MzcAE6Zz8XKUDUTJQS1s5iLxsKlVQTTIGqacuVRC+U2EagnG0aDjvp4qH14HFxyt+WskNZs8dObU9l7n22AjXDljKejWDc3XB3fZc7USIR3xdDrx5tFrC7PIlfxPmjC+XLKC1RJQknfxBhVJMKKYTqawXfUsghtgd36OdKedvJlDtKPGuC30rtuQeYORzgniXmdZri5QV156YfGO1YwM8YHt3kMWUdnlRcuWL2Lq0bcynqjrZLPUc+QPFVK/J1VL/GXaa5u8BCFN3bmZtHlkjuN7o7gRWOoDMTfhOUuIODAtAD/XnKsfOyFc7sicd50D6u5Z3gibqSLrw00E98TgbeY7tamA4btKt3drup8FTiR2HTCFKFt+QzWxBrcXOm2OvYjrwVycGKdfCVBJ9og/lSTJBDpSwNUzirlI/5tDSWtkCavvsXJRP1TJGpepHOaUdMWOiaATN5BVwMEjwGKVfh5cP3+2qsaPelFUR5QSb7H1Tg0k6PErSwEGhs3Zcfdrr7rKrqqmJBBf5/TKXAoZL9wCJ3fwkm62PwgguXqHRBGebcOq95Y4Dnmd0EZ/rp0TH0Jl725V5ZuOA9xuqHdOhH71TUfOAcM0heT1bimxCgRmV/C9b9iJ84u5LkYqNpeNJoRbwKPBHqA/NUIQEpPSyet0u+i2Cy0OmV6MmnB1gY8HIGSjQ/8nRM22KTk2xOdQjUAeVTCL5NIclLMeE41DItK35N6FH2kZqQ1I0O/LKAPUDhfvPJ16RgnITZqxKdzTJOsrePwct8pidEND4/rx9C/Ya9sfW4Sw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ujdL/IBDZZVzHnCufx1gFtgSAvStV/k3Pxe2Eaft/pv8DIiniRPd8w9sVKl69zCt+m1r+S2Qb9/3arnfegv/1PMmDVvvVbGd6CoxFlFP4bG+g1w1aYdIPb+rCQGRJc0uudPvw2ql2hR+emjk8v+Mz/Zu3+hTKOsmDIRafvJHPmQ4YbqrjMyLXE2vnJXMhcTTeI/36Bnf7lUSzhVAMT3xFsE+jSJsIgNE6i3CcFOfx4Jjt9/VXPYRWBv/zqMqbYT4YD8OMeOpQFR5XV+tuFrC0AV2peNaYYFKaeeX6esGiKvxz/ZoEDcL+YxoziNOCeAWWdpY6326Oic8l0tPNE915mK2abC8cmSgBg9GTBoGwX7IaIjF50v0KkZ6oGalKyyY2U1Gj3GBeRgMnFk737yeQS3HDPntBDoP2g1tFyZVxG9s1ODRiY8ui36iPOvKnBHBPuTaM1CVTwCzgI/dKFiMDuV24CsQnPcUx2tUZRY8bYfIG3IjZ5c3OZtd1LHJVyalrWJZEbhWX+USnan8R+eVzSNjEvpdFnEj+v0VhJFyfdr9cNaKDjY7MH86GfMAE3NWW0Bzx3fkd8zP87U/9uZ2ZIPOoglYALwWXar8uz1h5tz4FtohnQaEe60L1RXxLvsb5bBCmJl7G138TpkA53Y3xdCktG2kDqFUaJmhNRNlcC3M5Wu0Cywof909T8qg+spDL973tJ3wEU+OObrpIE134Hu0Djd5VvmdkZjSdAudZoe9pHiEhYKC9qXau+SqqaEkLTZQmW058jTCtdcKsAZo9qRmniWFfYnjj0PWA2+VppPHrnNNPtQWaP1FtXITS2Zo+UFFTdgckx3fNqth6gKnA47LO6GCM85K5n6skk/ZClM4KyJWwRI50t3TjRoOHNmtGIgtHuxf95EdT4EbKAuAbYCcnqIXUKzz8NVjPz6YrdLZl+r9So6AAerZ5dY0q2ESgj2iY54HuiD5EQ3vzsKxJVS48ECwxcoqYnEw7Y9n0wZfLOMtktvrFgZd6b4tqxKMYlD0ByrjGXt7h56SdNJN48ta/2Sc/bTVh/oJfts9zGNl+HbhQ1pyKwdQxW1XKHUGVcGCfRgWfprDe4K5YH9DMAmfGojHgPf70+wYF4iNIAfyrB1UPbzICIvuRF97HMYuy+3F93j5Rfx+5cTu8fwlhCUcwtdAPmW/FzyJYSYcqMIo6CHRlE/SIadolPANXfxdiztWFwJvy93sqv0GPPlviYIas6LY3Zqr8SXNW5jrPjBbJc7dJeqpcyAQXr6Rp9sgx0bYTZqeCnGsr3oa18gPrgwJ1Qogaf5W379ASwKVDNbaN+eq5rh64bObg+yg/FtbRE7N3HS+/7XxJFyqW9g6HYURKoiN9zzgdZKSbVSF955ma2rxdEyg7gPZ8Q+vrDKU9cFfCARD7mThyPffnF+holK172eEuDVVm8Z9TzTh45/LspmaNc3O38DwiQ4sxjvHnS+71iX+EKGTYNeU0Y3nkLKz+5URjH7RbJ93o5W6hGtCHVoDOMzpVusGUbKiVKcqblmInY39VUYKjz7TNJ1t2+Rbdv4eRIUD8d487aJiSsLCJzVKCnT0SAVPUmnvCpeNMzdmxyHBO0P4os45aMGD2S7RcIvDnaaGNAWI15M5qDw= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd3bf716-b40f-4a42-37a7-08dda9978663 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:21.7782 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BFbyA7q3YPj9rQGKvIlj271qs7Xbyj2qnPaoyje8dCh6jg8p96nWG0KtZRSwtR+LFOEJKzQboLWrW3BNt8YogkC3ZRHv9fkvQJhfcY2AyPg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=f+xIBPyM c=1 sm=1 tr=0 ts=684aa483 cx=c_pps a=oHfdRNjjH91Dx1UII95wnA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=7ZBXszWF_8vsTP3PHmcA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfXw4sFWcxK/022 QSeJnWP2GVPPbPjKba9uDkdUNLqwbJyNBJ8MQLswPerdyzN9Vxd93hpnsQbT9HI+pKiCGkSF0Vh HGhLVjzrRO3gYOScMIPqg4oaM3i3vLZUo1eOZcUj6ePgO2k6NN46hAhz0MrQX95uLx0DMooj1ok 34Z8gi9S3ejCiCvToiufY57im06h8OQP5mJ2J0SCz5YqxmuXgqnHmzZFVtlCX2gzAZ0SB8D1X3N eA94H2QXVQ6iU8IDsEYRw5qPpn5wQ2Ifve/m1AB+MpvsTWdAS1DQnoV2zOsJls/jotHP8kHwYnt UeUyPRX+dRabjgqVy/emKy19wI67qy93f6VXBPbKMoQ9MR3/rWjT+W2AyeH3kAF+1uOm0YToUC3 9RfwCHvRFyJzoX3yPevTaxbpv/3dmXGk3lyEEIYCgwchwIhhqEcPnRiCpybmoN0BPkW9Wzgz X-Proofpoint-ORIG-GUID: e8ytLNRgxTnUi8KU0PZvpZ8KZxXw2Avk X-Proofpoint-GUID: e8ytLNRgxTnUi8KU0PZvpZ8KZxXw2Avk X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:33 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218498 From: Sunil Dora The following commits have been cherry-picked from the Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [ee6c14ed59d480720721aaacc5fb03213dc153da] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-6.patch | 171 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 172 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-6.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-6.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-6.patch new file mode 100644 index 0000000000..d117cae9b7 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-6.patch @@ -0,0 +1,171 @@ +From 082e8146a1ca100d6ae15000e04b5e9cf6423a6c Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Wed, 11 Jun 2025 22:46:27 -0700 +Subject: [PATCH] nptl: Fix indentation + +In my previous change I turned a nested loop into a simple loop. I'm doing +the resulting indentation changes in a separate commit to make the diff on +the previous commit easier to review. + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [ee6c14ed59d480720721aaacc5fb03213dc153da] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_wait.c | 134 ++++++++++++++++----------------------- + 1 file changed, 55 insertions(+), 79 deletions(-) + +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index d1714a0c..2cbc567f 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -410,89 +410,65 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + return err; + } + +- +- while (1) +- { +- /* Now wait until a signal is available in our group or it is closed. +- Acquire MO so that if we observe (signals == lowseq) after group +- switching in __condvar_quiesce_and_switch_g1, we synchronize with that +- store and will see the prior update of __g1_start done while switching +- groups too. */ +- unsigned int signals = atomic_load_acquire (cond->__data.__g_signals + g); +- uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); +- unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; +- +- if (seq < (g1_start >> 1)) +- { +- /* If the group is closed already, +- then this waiter originally had enough extra signals to +- consume, up until the time its group was closed. */ +- break; +- } +- +- /* If there is an available signal, don't block. +- If __g1_start has advanced at all, then we must be in G1 +- by now, perhaps in the process of switching back to an older +- G2, but in either case we're allowed to consume the available +- signal and should not block anymore. */ +- if ((int)(signals - lowseq) >= 2) +- { +- /* Try to grab a signal. See above for MO. (if we do another loop +- iteration we need to see the correct value of g1_start) */ +- if (atomic_compare_exchange_weak_acquire ( +- cond->__data.__g_signals + g, ++ while (1) ++ { ++ /* Now wait until a signal is available in our group or it is closed. ++ Acquire MO so that if we observe (signals == lowseq) after group ++ switching in __condvar_quiesce_and_switch_g1, we synchronize with that ++ store and will see the prior update of __g1_start done while switching ++ groups too. */ ++ unsigned int signals = atomic_load_acquire (cond->__data.__g_signals + g); ++ uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); ++ unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; ++ ++ if (seq < (g1_start >> 1)) ++ { ++ /* If the group is closed already, ++ then this waiter originally had enough extra signals to ++ consume, up until the time its group was closed. */ ++ break; ++ } ++ ++ /* If there is an available signal, don't block. ++ If __g1_start has advanced at all, then we must be in G1 ++ by now, perhaps in the process of switching back to an older ++ G2, but in either case we're allowed to consume the available ++ signal and should not block anymore. */ ++ if ((int)(signals - lowseq) >= 2) ++ { ++ /* Try to grab a signal. See above for MO. (if we do another loop ++ iteration we need to see the correct value of g1_start) */ ++ if (atomic_compare_exchange_weak_acquire ( ++ cond->__data.__g_signals + g, + &signals, signals - 2)) +- break; +- else +- continue; +- } +- +- /* No signals available after spinning, so prepare to block. +- We first acquire a group reference and use acquire MO for that so +- that we synchronize with the dummy read-modify-write in +- __condvar_quiesce_and_switch_g1 if we read from that. In turn, +- in this case this will make us see the advancement of __g_signals +- to the upcoming new g1_start that occurs with a concurrent +- attempt to reuse the group's slot. +- We use acquire MO for the __g_signals check to make the +- __g1_start check work (see spinning above). +- Note that the group reference acquisition will not mask the +- release MO when decrementing the reference count because we use +- an atomic read-modify-write operation and thus extend the release +- sequence. */ +- atomic_fetch_add_acquire (cond->__data.__g_refs + g, 2); +- +- // Now block. +- struct _pthread_cleanup_buffer buffer; +- struct _condvar_cleanup_buffer cbuffer; +- cbuffer.wseq = wseq; +- cbuffer.cond = cond; +- cbuffer.mutex = mutex; +- cbuffer.private = private; +- __pthread_cleanup_push (&buffer, __condvar_cleanup_waiting, &cbuffer); +- +- err = __futex_abstimed_wait_cancelable64 ( +- cond->__data.__g_signals + g, signals, clockid, abstime, private); +- +- __pthread_cleanup_pop (&buffer, 0); +- +- if (__glibc_unlikely (err == ETIMEDOUT || err == EOVERFLOW)) +- { +- __condvar_dec_grefs (cond, g, private); +- /* If we timed out, we effectively cancel waiting. Note that +- we have decremented __g_refs before cancellation, so that a +- deadlock between waiting for quiescence of our group in +- __condvar_quiesce_and_switch_g1 and us trying to acquire +- the lock during cancellation is not possible. */ +- __condvar_cancel_waiting (cond, seq, g, private); +- result = err; +- break; +- } ++ break; + else +- __condvar_dec_grefs (cond, g, private); +- ++ continue; + } + ++ // Now block. ++ struct _pthread_cleanup_buffer buffer; ++ struct _condvar_cleanup_buffer cbuffer; ++ cbuffer.wseq = wseq; ++ cbuffer.cond = cond; ++ cbuffer.mutex = mutex; ++ cbuffer.private = private; ++ __pthread_cleanup_push (&buffer, __condvar_cleanup_waiting, &cbuffer); ++ ++ err = __futex_abstimed_wait_cancelable64 ( ++ cond->__data.__g_signals + g, signals, clockid, abstime, private); ++ ++ __pthread_cleanup_pop (&buffer, 0); ++ ++ if (__glibc_unlikely (err == ETIMEDOUT || err == EOVERFLOW)) ++ { ++ /* If we timed out, we effectively cancel waiting. */ ++ __condvar_cancel_waiting (cond, seq, g, private); ++ result = err; ++ break; ++ } ++ } ++ + /* Confirm that we have been woken. We do that before acquiring the mutex + to allow for execution of pthread_cond_destroy while having acquired the + mutex. */ +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index 05f408065f..45e6dedecb 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -66,6 +66,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0026-PR25847-3.patch \ file://0026-PR25847-4.patch \ file://0026-PR25847-5.patch \ + file://0026-PR25847-6.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64826 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B356FC71143 for ; Thu, 12 Jun 2025 09:57:33 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web11.9129.1749722244775068734 for ; Thu, 12 Jun 2025 02:57:24 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C3YbaB027382 for ; Thu, 12 Jun 2025 09:57:24 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.63]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474cd95bnx-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:23 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FJXFF6ULJY2MPZ+KHSL+VflUa5MMVeoQ9tCRIxXn0hZRlbDFb2d/cUConweBRQbMLWOEkmsfjXy0HBdna7TUhYjQ+5IuXJdXQPwYTWvSi8xNkoVN5GOKPQ+X5PB0z8vKiP+jjK3Sd5sr/KqBAp5yiUmDd52pOcQ+i0bCqoMaQZmqAMdY/HFQrtJ18/BLGX17KjTyjtCu1WZ4YuaLqlPw0EucOMkRSw4Nwxc8Mb+iFZABjOrSPNMW8DoBKhL5Q3m4XwosW7DGiU/5cCRbgqrVXh/aWcSth6OfTFegk0bO4QwQ/D9S3Y7F/i5nCwrrpwugO606dYIV85CajuMirMyLlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PFrXq5YuOy/FOwcu2CVtMT/aWHab7C/WTsTNrRCiuz8=; b=Bo7A1bwPSAirRGPUJ/o/FHMW3lnhG+HqS0qFjl6BFFCRR+G6mTHxNxtWmGPTuXTCl3nnV+JjT0NcpuSEgFSFRB0xwyqI5wIBAbKtUYkvgExkPpWvSzoc66ho5LwqM2IGB3uaE4NQSAlR8uzGc4dU+024+oBMsPO3HllqinMQ4S9S5pYGAgUbIQ+V149BnhDWXpVgK/0xGa5IMWaElgHzJA5wS+HD/U8FT5tP/mW1Kmq5FG/UseMhXCV53dHWx/IsZL62pdu8pO8hPZxnNcuGquYKLVh8T2QEE2x3QNhA9cGVt3mzfbqbwzB7g/F9vl3kwR0/jv2IqgCb0/1xeNT5NA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:22 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:22 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 7/8] nptl: rename __condvar_quiesce_and_switch_g1 Date: Thu, 12 Jun 2025 02:56:38 -0700 Message-ID: <20250612095639.3630518-8-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: a6b30330-1480-42cc-b998-08dda99786c9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: g+L82JawVQMzWGZvYN1P1N8GAGx7zfY6b8UFNpaEja79zT+44IdWQ5OOXkBXbaGwWUcz4e/AJ/u08/tJ7lDfogu49zbkP9uofbMkJuXdy96uOBcN9vkvX/XTeAzT4kpz1g8s8hQ0EJIWlHM8aJeHV/2E41Pjf6cdFxwtb5ebOYXhB6kZLcc6Zheu2ZtbVzJzEwakfZiTyeWM6NvaeOWI5qsQJ96DOZvOxVmVJgUNQdmoirNb5ra+HAj2Nbw2F65hPD+ue2Lp8niISyFXlwDdehReEvNlADwFcaZvr/vk2O8XDYJCXRp1x79hR6l0t4sDxTT05vDJfa9paHJ/HrePkzywXnwva9hIFD97qEZ4jxRg53lIJDSVLaqMh6xmxYnB5iInO3sPj5tR44adYQBi4HbbAipdU3CpcFHa+4ovY05yAlsjaPobiGvkd3GLFewxrMGZLyIaZriAXfgtXcltwMg+ikxAXzYKsi9EeFQ+VU0jaYnMKOUNaoR6gymoEpKWxZCU+ukvp/v2jGHQ35wgIvfnKWK0P1lYOFt/LfKx1IAFyqxqlo2ZO2HtOgZxSSJHvfFtxpck8q7YToLBy+GF1CbgLQjxVrn2M9nSybZVsDHQ6DCEL12snavzixxFJBziDmdEVR644vxkmGSVIEqKh4S918kVmhTheiA4j9g74R87UXFyXKs5HhP6AHHIOfsg+rG6HTzm7BWw4tiCvvzyWWAG4rPxofF7a8L/Wl7ltxh9yin6gC3RGFzP5Bk3tVcZpgpT3YK5HwD4KWTeIPQEURga5Dnyu3HGBsfZukYkyUxCe9i94YWEFdyXAV8cgxNXSoCXF5oPav/w7y8FF+wrwRuQOfx3L9bIiJzko/Nf6+XSAhcaVSJq6l6q/A/jBNjPiel1Wag/3xbrvm2LnXQSVEqVKgm1FZ3LKW6cxVaIqjV5mIS4GKfEGNv5WiRYMNwc3pmCUMfbZOdD96RAMzBTaHYn78dWRuYduw6Rn3/1FTIzZ3T4xFpRJjXWCWcXVa28tTu8BfNNLzxX1xHYIO91JL6sV+xI8b4kveIxOdN+sC9gwvSIf7n6yoxV5o0vn9KKSiJOxjjEyAZ5dnZgZBUglkGmHmzLircp8GtP5ff1aTEbwRHrWCMq5ngIlr4FGAn8PvCY2NYS6zKMBVZiJSfKw1d7wkky0NOa2DvoPYPSl1EJWSKdZwQagW9dOKPz5f5ugv/GiDpNCuF2u66RhK5zfrW7kePDT2j82IGWPz9xEfGKOyz5osdRFFt73GpIOO4kdJC6Ve6RYfdbO8vWpGm3Ix8TzlKtSc/2hiamuWGR3wHmkDy+DvX6TpuvFis1VUWWPmgdnNztrVs+kS4lsw/q89yVqPl67XmlNB79BjzBC3AyI7ujCSCR8OpPh4Ux+zyVfjfhItF0VBYw9U7/urltaSB2vqkbWcU5jNNujwKHuzMJS/Xf8QrdcdrWwZOph+eZLy5SzNwloPmCYb8AeSpztU1/bqDonk2wVFat/BnO/lk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Sv1wWERZuZafzvSuxS/sMfo/cmEiphHRvYpNpND5Lalpa7ahOtmd4rdql/ETyYyte+JVZYWT9/Xoj5CEry7r8qdQm0NQ2oWDxFkP3+b8pH2kk6vvR1siFmks/ZsbBcGni5RzHVLhMpuR4PpJ+YFwddgzSrscpTPyQSR3p0LWxYEWQDjn2BFNuSJJfQGCB426iOtfcOrHmdCXVco0DrnTPTFbde6/pKlFzb9q0UuzOqZ1/8gha2MhtHkjocFvYCXBS1bix9GmFyVlyWxdjUhduwrb71Qts68gb5fq/27nQwerWtf3BbmySrdEC49QEdKddWlRcq4cy6kc1kaiJJLGkVi2ucCS5DZdFZguXpoa0M/2BQ+uq9E7CcMQWlRlImsHAC7oj1IpAIvpnMbawygCse2zpu0UzU1aSVQ3CecacxRRPQ818/Fffz99YdIjAXnX18KzxDmnERWZwrEi9OE5JXvqzqz1LqVoqz6KnWfjW0e3vXMt2cPiq6Wrgb+zoBgshihTUKOPi2ZhRJV2ZWrs9s6GfUiXSAfM0Qv9cycmnAp+jwQ4RopQvDvE8C6b8WKpw3zK28dA5IsTQCckh4+knexiOdE/9PUH40ALzj4fNUi4qQ7GKKzK2TfP5ehgYex2z1qbhoY1qm0tmKL211lvNXgduOjhZs5x44RxeqARPpx/nhdSyeG6b/VbLglgA9yY23sstLkkL689YOKjratm5oNpyeV0/AcNrrRM2xRtrdzi4PfLVB1exHEDSZ+8qusyJgWxO2pj/tjL6sIIbc+iVmONHGeSNqwr92hkF6UFa7+yjdLFVmniGmO60WY/mWD1eIV/B+vSjgVCAjbhOiw8wrAx4Hd8+AqFOHyANdF76BbiZL+ZkUw5/tJGxjIgp/LCp3k1j3uWqteMoB31CItrcD33B7bjhNG5PeCE3n86QbCZN/qm67eh94vlkx8t7QSEqg936Vbv6T97YrYb4CIEg9CLb3Xb7q+bj6mNykrM4zbqmMPLyYTi0aZ6fdZHVS/P7ok6F90roUwtxcmY86wgLzcaN5tQLZbBSmhIylPeS/I3P+46iqUzlZq4BOOkj0CngDTuX3wAhOA1sTOTYtpw4KvmY1hcCq86js7zBkgDl6syHNUaNO4vmUYizvnWreAfY4RK/6D8IaoOPeotYcRvnbmQ+evJNozS53RyfexWdOg7J5Ny1b7kygpD1556JV1wJOLKYfxLPFiNECZgBhkmI++p0rDoROpg1qsOR4uBflpFraDa0263CA9qkbB0x5NC2FuDm6zmq8lqA7GkBiwhw0IL6Xe6fOw/0LEoO1YbF5+jJRqNDI+Rr6ZTDCxxUdMmW16IPv4vdRm8apVt9pWwRQ/yCggBM3Ard7rvnGrGmF//fQYTjjDSt3GKZJlu3F5tsMUUasMBTVEFX4cqABeUEoclnsE9/OUtdqd1Vf/x+DV/J1s6rt6n72DxZRLUbXS3+kTLJQTJlapiIgpvZwX8MmSpFaSPUjv+/ToniXliSHiEuEsbjE8e/9C+9pqHoyM3y7ddpMTJlYaDBEopb/8HIb27shWLoGSnKpgBWIK0zqoSxs7FOFSemSHtJOqpcpZms8h8BjkuR0vZ3bfYjK8/huAebuPUeI9vpGz3dDi38ms= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6b30330-1480-42cc-b998-08dda99786c9 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:22.4330 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0H9wgETkQ1eZpyhAxi71SlWFX+kUDPqOHMNeqYgtIJESivAgRKAoD5iwrvFaRS0nExI73GlSY2Hd8E98o742ryYRbiNqZfgWNyOydGcsUM0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Authority-Analysis: v=2.4 cv=f+xIBPyM c=1 sm=1 tr=0 ts=684aa483 cx=c_pps a=oHfdRNjjH91Dx1UII95wnA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=s6aSZSq6sOFI80PhqW8A:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfXz6vo83GrTut9 QwgW/xo/s+L2nnnh0ZeZYi0FDwXgzKqt3BUzF6YvnqnwwbeELZPY0pb+RDBT7EZzXubU1eTkHBx JA+93/f+WiaiBgIbo0G9T9K8eKbmiLZ0T7EjGq4XGvQJwIgAMZZapdwvxArEMNeTkyloje9t0vz hlWmid65U2RmsVCV/lfrs5icUyYcGgjmqyGgEff255iJhy/y7+T0pEwuL9v6bBHA1iTXkOh+Oqx QvKleDdFsKMlU6u4o1IVHr9fy/awzhsYDUoM6tQObqV11iliudz5Ey0hiwRCfRrSysIYarhQ01N HtFL6GJ1cu7gmJsUG+xkAIfEM+qd68tSC8zAzptOJSwaoXUiOu7W5aIX5VK5XRVTNfbPPd1c5ow pFHKGoH/CXUNrTlgU/GPYow9GsmOVw1Ek70Umvdyv7nGMdvDBdKvms6dgFCh9fptBMMGxlEP X-Proofpoint-ORIG-GUID: ijZbiFboX_ano3LoxpLR1iwo8Crg91FR X-Proofpoint-GUID: ijZbiFboX_ano3LoxpLR1iwo8Crg91FR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:33 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218499 From: Sunil Dora The following commits have been cherry-picked from the Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [4b79e27a5073c02f6bff9aa8f4791230a0ab1867] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-7.patch | 159 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 160 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-7.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-7.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-7.patch new file mode 100644 index 0000000000..29aef6ebd6 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-7.patch @@ -0,0 +1,159 @@ +From 305380894e0144159e493dff6d71dbcbf07aeeb7 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 9 Jun 2025 07:01:40 -0700 +Subject: [PATCH] nptl: rename __condvar_quiesce_and_switch_g1 + +This function no longer waits for threads to leave g1, so rename it to +__condvar_switch_g1 + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [4b79e27a5073c02f6bff9aa8f4791230a0ab1867] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_broadcast.c | 4 ++-- + nptl/pthread_cond_common.c | 26 ++++++++++++-------------- + nptl/pthread_cond_signal.c | 17 ++++++++--------- + nptl/pthread_cond_wait.c | 9 ++++----- + 4 files changed, 26 insertions(+), 30 deletions(-) + +diff --git a/nptl/pthread_cond_broadcast.c b/nptl/pthread_cond_broadcast.c +index 5ae141ac..a0743558 100644 +--- a/nptl/pthread_cond_broadcast.c ++++ b/nptl/pthread_cond_broadcast.c +@@ -60,7 +60,7 @@ ___pthread_cond_broadcast (pthread_cond_t *cond) + cond->__data.__g_size[g1] << 1); + cond->__data.__g_size[g1] = 0; + +- /* We need to wake G1 waiters before we quiesce G1 below. */ ++ /* We need to wake G1 waiters before we switch G1 below. */ + /* TODO Only set it if there are indeed futex waiters. We could + also try to move this out of the critical section in cases when + G2 is empty (and we don't need to quiesce). */ +@@ -69,7 +69,7 @@ ___pthread_cond_broadcast (pthread_cond_t *cond) + + /* G1 is complete. Step (2) is next unless there are no waiters in G2, in + which case we can stop. */ +- if (__condvar_quiesce_and_switch_g1 (cond, wseq, &g1, private)) ++ if (__condvar_switch_g1 (cond, wseq, &g1, private)) + { + /* Step (3): Send signals to all waiters in the old G2 / new G1. */ + atomic_fetch_add_relaxed (cond->__data.__g_signals + g1, +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index f976a533..3baac4da 100644 +--- a/nptl/pthread_cond_common.c ++++ b/nptl/pthread_cond_common.c +@@ -189,16 +189,15 @@ __condvar_get_private (int flags) + return FUTEX_SHARED; + } + +-/* This closes G1 (whose index is in G1INDEX), waits for all futex waiters to +- leave G1, converts G1 into a fresh G2, and then switches group roles so that +- the former G2 becomes the new G1 ending at the current __wseq value when we +- eventually make the switch (WSEQ is just an observation of __wseq by the +- signaler). ++/* This closes G1 (whose index is in G1INDEX), converts G1 into a fresh G2, ++ and then switches group roles so that the former G2 becomes the new G1 ++ ending at the current __wseq value when we eventually make the switch ++ (WSEQ is just an observation of __wseq by the signaler). + If G2 is empty, it will not switch groups because then it would create an + empty G1 which would require switching groups again on the next signal. + Returns false iff groups were not switched because G2 was empty. */ + static bool __attribute__ ((unused)) +-__condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, ++__condvar_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + unsigned int *g1index, int private) + { + unsigned int g1 = *g1index; +@@ -214,8 +213,7 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + + cond->__data.__g_size[g1 ^ 1]) == 0) + return false; + +- /* Now try to close and quiesce G1. We have to consider the following kinds +- of waiters: ++ /* We have to consider the following kinds of waiters: + * Waiters from less recent groups than G1 are not affected because + nothing will change for them apart from __g1_start getting larger. + * New waiters arriving concurrently with the group switching will all go +@@ -223,12 +221,12 @@ __condvar_quiesce_and_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + are not affected. + * Waiters in G1 have already received a signal and been woken. */ + +- /* Update __g1_start, which finishes closing this group. The value we add +- will never be negative because old_orig_size can only be zero when we +- switch groups the first time after a condvar was initialized, in which +- case G1 will be at index 1 and we will add a value of 1. +- Relaxed MO is fine because the change comes with no additional +- constraints that others would have to observe. */ ++ /* Update __g1_start, which closes this group. The value we add will never ++ be negative because old_orig_size can only be zero when we switch groups ++ the first time after a condvar was initialized, in which case G1 will be ++ at index 1 and we will add a value of 1. Relaxed MO is fine because the ++ change comes with no additional constraints that others would have to ++ observe. */ + __condvar_add_g1_start_relaxed (cond, + (old_orig_size << 1) + (g1 == 1 ? 1 : - 1)); + +diff --git a/nptl/pthread_cond_signal.c b/nptl/pthread_cond_signal.c +index 14800ba0..a9bc10dc 100644 +--- a/nptl/pthread_cond_signal.c ++++ b/nptl/pthread_cond_signal.c +@@ -69,18 +69,17 @@ ___pthread_cond_signal (pthread_cond_t *cond) + bool do_futex_wake = false; + + /* If G1 is still receiving signals, we put the signal there. If not, we +- check if G2 has waiters, and if so, quiesce and switch G1 to the former +- G2; if this results in a new G1 with waiters (G2 might have cancellations +- already, see __condvar_quiesce_and_switch_g1), we put the signal in the +- new G1. */ ++ check if G2 has waiters, and if so, switch G1 to the former G2; if this ++ results in a new G1 with waiters (G2 might have cancellations already, ++ see __condvar_switch_g1), we put the signal in the new G1. */ + if ((cond->__data.__g_size[g1] != 0) +- || __condvar_quiesce_and_switch_g1 (cond, wseq, &g1, private)) ++ || __condvar_switch_g1 (cond, wseq, &g1, private)) + { + /* Add a signal. Relaxed MO is fine because signaling does not need to +- establish a happens-before relation (see above). We do not mask the +- release-MO store when initializing a group in +- __condvar_quiesce_and_switch_g1 because we use an atomic +- read-modify-write and thus extend that store's release sequence. */ ++ establish a happens-before relation (see above). We do not mask the ++ release-MO store when initializing a group in __condvar_switch_g1 ++ because we use an atomic read-modify-write and thus extend that ++ store's release sequence. */ + atomic_fetch_add_relaxed (cond->__data.__g_signals + g1, 2); + cond->__data.__g_size[g1]--; + /* TODO Only set it if there are indeed futex waiters. */ +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index 2cbc567f..eb32291d 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -382,8 +382,7 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + because we do not need to establish any happens-before relation with + signalers (see __pthread_cond_signal); modification order alone + establishes a total order of waiters/signals. We do need acquire MO +- to synchronize with group reinitialization in +- __condvar_quiesce_and_switch_g1. */ ++ to synchronize with group reinitialization in __condvar_switch_g1. */ + uint64_t wseq = __condvar_fetch_add_wseq_acquire (cond, 2); + /* Find our group's index. We always go into what was G2 when we acquired + our position. */ +@@ -414,9 +413,9 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + { + /* Now wait until a signal is available in our group or it is closed. + Acquire MO so that if we observe (signals == lowseq) after group +- switching in __condvar_quiesce_and_switch_g1, we synchronize with that +- store and will see the prior update of __g1_start done while switching +- groups too. */ ++ switching in __condvar_switch_g1, we synchronize with that store and ++ will see the prior update of __g1_start done while switching groups ++ too. */ + unsigned int signals = atomic_load_acquire (cond->__data.__g_signals + g); + uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); + unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index 45e6dedecb..547d0a3d7d 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -67,6 +67,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0026-PR25847-4.patch \ file://0026-PR25847-5.patch \ file://0026-PR25847-6.patch \ + file://0026-PR25847-7.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \ From patchwork Thu Jun 12 09:56:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Dora, Sunil Kumar" X-Patchwork-Id: 64828 X-Patchwork-Delegate: steve@sakoman.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFDE6C71141 for ; Thu, 12 Jun 2025 09:57:33 +0000 (UTC) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web11.9130.1749722246934219066 for ; Thu, 12 Jun 2025 02:57:27 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.178.238, mailfrom: prvs=8258e96b79=sunilkumar.dora@windriver.com) Received: from pps.filterd (m0250811.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55C7welC020387 for ; Thu, 12 Jun 2025 09:57:26 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10on2065.outbound.protection.outlook.com [40.107.92.65]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 474an2ndym-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Jun 2025 09:57:25 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=I1tn9u6A/SkIGxs6GdZe2XRImB1lVj2qC8T4cmpFVBhkqC8tclCMHJ+tbTHxYSX6/4fAe3cSL1ixOXUrdMN4FEsaNzzBUz5CZk+S4CNnnNZIeYZ3VFS1zi54PLQ5u9JJ2NPaT+RpFKzQbWowzQxoi8HBHHlk2Hj9KHf5S+s0DRTTVsk8Rfg3bejUbHK4fQCgMuh9qAc+j0uJxGYJ9vc+B7ayGxR2nAh/N9vtaf8nMjVdgofMfnZ+oI9QLCQfwheVCR07v1Vi6whmaYnNVACyZCqWCoT91q2sKQZIOgghmA0rVfazDfJ0Gmy5ubzbGtOaLicWVFizoDbNX23R1qqIRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GXZMppbQU2MZQYOuh9884A3SSQCluLQgKeJTUqIV3H4=; b=kjmZ2XTWvPj7J/Q0LFEu+dgScTZ7suGFH/iUccUYKqLKHSzu9dudTTs4OkHMA3N2D+JKjNLd4ebOPwGY9bPIC/yuPFzZDv8zooy3bM+RmAlVoIsNMG0AV7hVj290cTSFTXiJypqMsPBmeJ38EmZo4YN35XhQmoSyyMQm37//8YVgbVj/wKiZs1zMK2RGT+QMKGEa+Ard5RUENweh1YHHEeNA/s+RG92TdxeiVpaJvcckSgywYTXM1H8YYbs+VAaWtFbHBJq65mdLMg+e3BezEmt3Ya3Hr0/lMlqvCe2RYGIN7l6mKnHigtK4rbbms1+b0gwaMJKlIQKubQ4Krr/NSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) by PH3PPF2B89F77E0.namprd11.prod.outlook.com (2603:10b6:518:1::d11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.20; Thu, 12 Jun 2025 09:57:23 +0000 Received: from DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d]) by DS0PR11MB7901.namprd11.prod.outlook.com ([fe80::9fa:eb3f:cf26:264d%4]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025 09:57:23 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, =SunilKumar.Dora@windriver.com Subject: [kirkstone][PATCH V2 8/8] nptl: Use all of g1_start and g_signals Date: Thu, 12 Jun 2025 02:56:39 -0700 Message-ID: <20250612095639.3630518-9-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> References: <20250612095639.3630518-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: PH0P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::11) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|PH3PPF2B89F77E0:EE_ X-MS-Office365-Filtering-Correlation-Id: 376846d6-b8f3-40d9-13ee-08dda997872f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|52116014|13003099007|38350700014; X-Microsoft-Antispam-Message-Info: EJvu1I3in/9F7m7VBx19uxJh2SUL2eTlefCqGkBLUuqVAsC2T2Z3ha5pbTP9GgyU1j9S42FPdinTDmMcJaJzn1gvT2wLJJQFvn80GFaySJrVHCFAzHgARWsYt8Ud34lH7nM8xTvJtTQh4WDY14gwjXWUFB4f6SmHlHCy0QD4ZHER4Tt2AeIA6woRl/z4nH6TBplNqaEoYgoScPpZXEMqoEFEpcFIxcKafCUQPwJD2+5+6ZrklO9FCH4zb/po6mjynp06TX2JoRMbjyiUlf2zP+3WcHW8tFdz+iz7iKUpYGIx6YdThBnahkRlG4unjIUDuXFKyugol4SbtDwGjHQYi2lIiPqqAoCYvTbbrJj7AoYEz1H5x+/CTLKCh29JBV26b9ODQJh0pxZUten84n0OnoGDBp/fL8ocWSyRHR+4JzwfJ9+mrcdlFobWr7OaWfd9UjyA3gYd4yUuuVHGp5CEozoigg66gtFWzvWXOBCONkVEQrPmrS7eZbbflzuU12p5SbKMJn8wRC/bm8XSPjecvqs6fos0sPJjUSKKIzOf1Mf6IdiVnHREjLKztvaUvuAlFqmPYX5rAQvJT+jZ54bXXHr9PQ0bUMlG7gOgyeM4AOHBOxj3J6GvjH10WcW1BKMDo/eAHPZTXYiI7d1l8/JBw1LK+8UbVk6vIBSyfHbhLn9G7ot9vzBJ7YDNhFEzOZqaXFk16oHS5rYlGur3TGscIFjAuVS77jQVNybQC3/lYXzk6HBxYqgFs+uCwTFth00/SnkWoR2Juw+XLPaE8mOydmKJtkSI/ajnyt/XKH7Oj7M7fTYJi/ApDN31lqgxP7/YFVFeGVM6GSZFxDnwdXaKoHtHiYKaCTCQiHhJQJQIDNQjbt4iP1VQgXJu+x7H0X95Mw3QtvsZe7RxlqTuJlenIDIMPTEOvL0DyYKgWAiorgn17H+2c4oxZQ7zjilXMtdvTveUMg9zVMvmjyRNM1BAez8MVp838Z4JrWlqUsNmI4u8ukp6EjPcI5fyqgOc7waA1iWwN0zjX1shUAL1b8BeeDrqJydHrXTDprIoPzO8AN+o8ACvvAm/EFDVxjj6onuS22FXtpeXljovi+TBaCojRMQNRcOKkB6KFG18Uqq4P+bZHNRNzYhcHv5CgXNunPL8VDCcxcr0eEa5aaOriL5TPfSkkpAjVoGewKQnngDToiwRUMF1CurntILRqyjHBGHn+VBQwszbNt+RsxXMCRmFlv4yGIPa1TXpoPWP0V8fHzH16WTowi2LeAbNPNFz3ox8RwC/YR1vquw+cNg72aUosqmBx1YcVhUPIu5X/gDLG71PDFWLNtRPz2cw+MqS3dhCXF1xxhHdLM8771W8vcQJT4rnsNe8tjSKv0o11bGsvH81EYP5gBYWbUTSBUcr7/cwduaMLIppVjcft1tl7/11+nzTwKYb3xG5CLU8/hNAbOMm8w1n5vXxILCdn2ljN54F7cem9Qnvf0fvCALJ6+5ByNnOsAzAGzBNakkzNn8iQZM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7901.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(13003099007)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EErr+jhI9aVCI8WT1Ax7Oy9Uwv1OBAi/BGE3TvBaw/qqpT06JHidPQsWqFEIHHQWHfOYtBsLbvBQz0VsrhjAdKBfYwSibcpUSb3U3gTIOpjA9SC5zlA8azN3UWcHNyjkvA3cGPA62bzj8B1zUg9PnIY6pl2Us8WDM2F7GKaQh5m1OthziqYwriaZftWOb0myoN7wkY9DptdPQYSK9q0Yaen1+pRSvhLlufzSr/3E68PzrLWwnwH8v6MfzdRqukgnK8Una743FO9UFBu6JYVIDnfPF890RC9p/Z8uATUB8FqI7mPH4cfgd+lZsGup4gL2nVyH0dQ+Ew7MaegN1BiSC6Zfrx3g5Q6sgRjh2SJoCV+YtCKZ9k8IsTmXVvppOmrZFDmu2X+akY7I92cflpdSq8Agu+ltG7HBQpHbf3xq97AaBygOB6OAJkx1iqn/WQw6FnpX2AuazJwI8f+moJNdGqmlNGd/GYbGUyEwrjGuo3l0XDmx1Lgigdv8+n7Brs3IIbI1TBa44zUwhs0WlqqTj0rvzxqOlSbOr4LX8dt8p0ZHndElxnHP/LsPNZv+uVr8L0xXwG5pec/QRIZ/zbzvIvaIpto24ImwhuPJob/57Cy3hI8d6kYyns3xOg++A0aVC4U1udjyLuhiIxV2SsL6tjFSOqbATj9SKMjW+4QSeS3zZm8NYtmV0+6C4frIFXt1bbKW9UbKzHJetdk0A7soPElheIozTpKW7/MxrVrRQVyYA53Sgd/or4l8blvjzijqu6nT3I+hcjM3anR+1eo7+W6uvB1IKPhN7oSbBo9FE/+t4bnRJuUIBHwi/VSjer0eT5+hTV4HzU7Uft5afodCMH2q0jYNwj4W4468qj//EyxI3H7IgPMi3S+nzsEpbg9rS+m/eznVKZqHFA6INLsIyKFe08PDT0/DYcxQ/a1VVpuczLUC9gIKdSAoKHAwYKlRtzy0pQ6d1Bh4YzeeqYTfnLp1b6xz+LtFQHgjwGRZu/GVvw3V/aNWZIVa444BtLtbh7n54180h37EFdFPwnWcKdNm0KWWp8Xx7odIBDLly1lLJgrlf6fvdNAdQVilX+uOM1x+MlJouHH94OdNZRS12mQBibhn9fYLTrDxiJYq2SLCnzMIomXkrK2YXABmg4BNhPqSBULymE1FCrzSUZYF8sOO4/TSi+dyZYqZPYhMqCEQ+JVnmqnU0p+IAM5yQR1+gnR9OS1NTYiHZEgNRa59vlyCZ5A6vqr6o1GXGnGj6nWqNWG8FiU2kH2z7z4qnmHkPClP0BEtdYXxSQLozz7nrFPLn+6jkZgW41jvdN7fCEIBSW4J7dZiS8p16PiIDtiQd5OkRpMN2n1U26NUMV6ZcNbX5IfhmToOt6+5c4ghvH7CmevH2eHruyziAIjo0XisttX8CTBshSC7lSaAyf0a4NEBa+hRBt2nRU5/IKrfliM5EmcMh5V3sv/hHNlzmXhwGSwabmG9ysYY1YLM7MrfKg4LC7LobkrG5nqfiwBbPqTJrDo5tWkothpbMbVxSVYP4ddCOypeGMsxVxsaawED+dtcfacoTB2YjVVa639rximLtbaLSyZsiV7BzsfksZ3K1kptxL6UuNVNmx5T3c32mGAd+78t8gKjvSAVerNe9t8= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 376846d6-b8f3-40d9-13ee-08dda997872f X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:57:23.1508 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qkmZ2cbG+GJP515AIbMZ/NSITIkSmVYt2Ocug01LXlqeoXrTajJZ7pQOLBVJh9Bwjqn8uvYm3cnmYgdI0mf2k7xQZXJ+zXW22dw8YAwfcHg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPF2B89F77E0 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDA3NiBTYWx0ZWRfX524VuTJ0bpFK /42ngHqwB2qENKvpuPQNIa/LZ2sRgSThEfUsrEIWrOxI4HZUWXEXLmmHRRIANPezAv7S7Wu8J7g GVuksG+tryrxSy3Eznzv8tu6OiZVvCFU4YY6ggZIZa1h9Kt43+upBl2pw43GKewydqx4SQqNtbB s3RdU2Y5WfmZ4yezA6+ab0DsQ/yAwGPuCmFHa4B9gRMaHEwUvXm7ZfSQoGUno55YI3uEG+3wwPL HOeeMNsQqV/khr9AW2NsSCcFYn9YJ1I62/HNghN8D2wtDzLay+O2nFzOHmB8vvtI8iFAHD4K1cE xch0kqgGKo5scLIIngLt4udRfLC6T28Cu4y7Ha8rrYpkPLRKVo10AkyBX9y3iK31bg5JHoAqYnA HVV36BW+f39rqUNda8ULglveT/5CaQ9sX/Bst/9vgtNvM3OrvFXFJB5qLmx9Sfaqp6NVQqlD X-Proofpoint-GUID: KX9sItZudnIG2Lj5aRvsB84iKvAbZcP9 X-Authority-Analysis: v=2.4 cv=fdSty1QF c=1 sm=1 tr=0 ts=684aa485 cx=c_pps a=z2JJcCkshELlDGyO4lBz5A==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=6IFa9wvqVegA:10 a=CCpqsmhAAAAA:8 a=t7CeM3EgAAAA:8 a=X6uU5uM_jJMz_PZaGGwA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-ORIG-GUID: KX9sItZudnIG2Lj5aRvsB84iKvAbZcP9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-12_07,2025-06-10_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 clxscore=1015 malwarescore=0 suspectscore=0 mlxscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506120076 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 12 Jun 2025 09:57:33 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218500 From: Sunil Dora The following commits have been cherry-picked from the Glibc master branch: Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 Upstream-Status: Backport [91bb902f58264a2fd50fbce8f39a9a290dd23706] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-8.patch | 191 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 192 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/0026-PR25847-8.patch diff --git a/meta/recipes-core/glibc/glibc/0026-PR25847-8.patch b/meta/recipes-core/glibc/glibc/0026-PR25847-8.patch new file mode 100644 index 0000000000..8480bbcaf4 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-8.patch @@ -0,0 +1,191 @@ +From 2801c1dd83ca923c4e4ea232393b3c58667093d6 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Wed, 11 Jun 2025 23:01:38 -0700 +Subject: [PATCH] nptl: Use all of g1_start and g_signals + +The LSB of g_signals was unused. The LSB of g1_start was used to indicate +which group is G2. This was used to always go to sleep in pthread_cond_wait +if a waiter is in G2. A comment earlier in the file says that this is not +correct to do: + + "Waiters cannot determine whether they are currently in G2 or G1 -- but they + do not have to because all they are interested in is whether there are + available signals" + +I either would have had to update the comment, or get rid of the check. I +chose to get rid of the check. In fact I don't quite know why it was there. +There will never be available signals for group G2, so we didn't need the +special case. Even if there were, this would just be a spurious wake. This +might have caught some cases where the count has wrapped around, but it +wouldn't reliably do that, (and even if it did, why would you want to force a +sleep in that case?) and we don't support that many concurrent waiters +anyway. Getting rid of it allows us to use one more bit, making us more +robust to wraparound. + +The following commits have been cherry-picked from the master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport [91bb902f58264a2fd50fbce8f39a9a290dd23706] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_broadcast.c | 4 ++-- + nptl/pthread_cond_common.c | 26 ++++++++++---------------- + nptl/pthread_cond_signal.c | 2 +- + nptl/pthread_cond_wait.c | 14 +++++--------- + 4 files changed, 18 insertions(+), 28 deletions(-) + +diff --git a/nptl/pthread_cond_broadcast.c b/nptl/pthread_cond_broadcast.c +index a0743558..ef0943cd 100644 +--- a/nptl/pthread_cond_broadcast.c ++++ b/nptl/pthread_cond_broadcast.c +@@ -57,7 +57,7 @@ ___pthread_cond_broadcast (pthread_cond_t *cond) + { + /* Add as many signals as the remaining size of the group. */ + atomic_fetch_add_relaxed (cond->__data.__g_signals + g1, +- cond->__data.__g_size[g1] << 1); ++ cond->__data.__g_size[g1]); + cond->__data.__g_size[g1] = 0; + + /* We need to wake G1 waiters before we switch G1 below. */ +@@ -73,7 +73,7 @@ ___pthread_cond_broadcast (pthread_cond_t *cond) + { + /* Step (3): Send signals to all waiters in the old G2 / new G1. */ + atomic_fetch_add_relaxed (cond->__data.__g_signals + g1, +- cond->__data.__g_size[g1] << 1); ++ cond->__data.__g_size[g1]); + cond->__data.__g_size[g1] = 0; + /* TODO Only set it if there are indeed futex waiters. */ + do_futex_wake = true; +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index 3baac4da..e48f9143 100644 +--- a/nptl/pthread_cond_common.c ++++ b/nptl/pthread_cond_common.c +@@ -208,9 +208,9 @@ __condvar_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + behavior. + Note that this works correctly for a zero-initialized condvar too. */ + unsigned int old_orig_size = __condvar_get_orig_size (cond); +- uint64_t old_g1_start = __condvar_load_g1_start_relaxed (cond) >> 1; +- if (((unsigned) (wseq - old_g1_start - old_orig_size) +- + cond->__data.__g_size[g1 ^ 1]) == 0) ++ uint64_t old_g1_start = __condvar_load_g1_start_relaxed (cond); ++ uint64_t new_g1_start = old_g1_start + old_orig_size; ++ if (((unsigned) (wseq - new_g1_start) + cond->__data.__g_size[g1 ^ 1]) == 0) + return false; + + /* We have to consider the following kinds of waiters: +@@ -221,16 +221,10 @@ __condvar_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + are not affected. + * Waiters in G1 have already received a signal and been woken. */ + +- /* Update __g1_start, which closes this group. The value we add will never +- be negative because old_orig_size can only be zero when we switch groups +- the first time after a condvar was initialized, in which case G1 will be +- at index 1 and we will add a value of 1. Relaxed MO is fine because the +- change comes with no additional constraints that others would have to +- observe. */ +- __condvar_add_g1_start_relaxed (cond, +- (old_orig_size << 1) + (g1 == 1 ? 1 : - 1)); +- +- unsigned int lowseq = ((old_g1_start + old_orig_size) << 1) & ~1U; ++ /* Update __g1_start, which closes this group. Relaxed MO is fine because ++ the change comes with no additional constraints that others would have ++ to observe. */ ++ __condvar_add_g1_start_relaxed (cond, old_orig_size); + + /* At this point, the old G1 is now a valid new G2 (but not in use yet). + No old waiter can neither grab a signal nor acquire a reference without +@@ -242,13 +236,13 @@ __condvar_switch_g1 (pthread_cond_t *cond, uint64_t wseq, + g1 ^= 1; + *g1index ^= 1; + +- /* Now advance the new G1 g_signals to the new lowseq, giving it ++ /* Now advance the new G1 g_signals to the new g1_start, giving it + an effective signal count of 0 to start. */ +- atomic_store_release (cond->__data.__g_signals + g1, lowseq); ++ atomic_store_release (cond->__data.__g_signals + g1, (unsigned)new_g1_start); + + /* These values are just observed by signalers, and thus protected by the + lock. */ +- unsigned int orig_size = wseq - (old_g1_start + old_orig_size); ++ unsigned int orig_size = wseq - new_g1_start; + __condvar_set_orig_size (cond, orig_size); + /* Use and addition to not loose track of cancellations in what was + previously G2. */ +diff --git a/nptl/pthread_cond_signal.c b/nptl/pthread_cond_signal.c +index a9bc10dc..07427369 100644 +--- a/nptl/pthread_cond_signal.c ++++ b/nptl/pthread_cond_signal.c +@@ -80,7 +80,7 @@ ___pthread_cond_signal (pthread_cond_t *cond) + release-MO store when initializing a group in __condvar_switch_g1 + because we use an atomic read-modify-write and thus extend that + store's release sequence. */ +- atomic_fetch_add_relaxed (cond->__data.__g_signals + g1, 2); ++ atomic_fetch_add_relaxed (cond->__data.__g_signals + g1, 1); + cond->__data.__g_size[g1]--; + /* TODO Only set it if there are indeed futex waiters. */ + do_futex_wake = true; +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index eb32291d..2e244e81 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -84,7 +84,7 @@ __condvar_cancel_waiting (pthread_cond_t *cond, uint64_t seq, unsigned int g, + not hold a reference on the group. */ + __condvar_acquire_lock (cond, private); + +- uint64_t g1_start = __condvar_load_g1_start_relaxed (cond) >> 1; ++ uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); + if (g1_start > seq) + { + /* Our group is closed, so someone provided enough signals for it. +@@ -278,7 +278,6 @@ __condvar_cleanup_waiting (void *arg) + * Waiters fetch-add while having acquire the mutex associated with the + condvar. Signalers load it and fetch-xor it concurrently. + __g1_start: Starting position of G1 (inclusive) +- * LSB is index of current G2. + * Modified by signalers while having acquired the condvar-internal lock + and observed concurrently by waiters. + __g1_orig_size: Initial size of G1 +@@ -299,11 +298,9 @@ __condvar_cleanup_waiting (void *arg) + * Reference count used by waiters concurrently with signalers that have + acquired the condvar-internal lock. + __g_signals: The number of signals that can still be consumed, relative to +- the current g1_start. (i.e. bits 31 to 1 of __g_signals are bits +- 31 to 1 of g1_start with the signal count added) ++ the current g1_start. (i.e. g1_start with the signal count added) + * Used as a futex word by waiters. Used concurrently by waiters and + signalers. +- * LSB is currently reserved and 0. + __g_size: Waiters remaining in this group (i.e., which have not been + signaled yet. + * Accessed by signalers and waiters that cancel waiting (both do so only +@@ -418,9 +415,8 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + too. */ + unsigned int signals = atomic_load_acquire (cond->__data.__g_signals + g); + uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); +- unsigned int lowseq = (g1_start & 1) == g ? signals : g1_start & ~1U; + +- if (seq < (g1_start >> 1)) ++ if (seq < g1_start) + { + /* If the group is closed already, + then this waiter originally had enough extra signals to +@@ -433,13 +429,13 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, + by now, perhaps in the process of switching back to an older + G2, but in either case we're allowed to consume the available + signal and should not block anymore. */ +- if ((int)(signals - lowseq) >= 2) ++ if ((int)(signals - (unsigned int)g1_start) > 0) + { + /* Try to grab a signal. See above for MO. (if we do another loop + iteration we need to see the correct value of g1_start) */ + if (atomic_compare_exchange_weak_acquire ( + cond->__data.__g_signals + g, +- &signals, signals - 2)) ++ &signals, signals - 1)) + break; + else + continue; +-- +2.49.0 + diff --git a/meta/recipes-core/glibc/glibc_2.35.bb b/meta/recipes-core/glibc/glibc_2.35.bb index 547d0a3d7d..b5f1535b83 100644 --- a/meta/recipes-core/glibc/glibc_2.35.bb +++ b/meta/recipes-core/glibc/glibc_2.35.bb @@ -68,6 +68,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0026-PR25847-5.patch \ file://0026-PR25847-6.patch \ file://0026-PR25847-7.patch \ + file://0026-PR25847-8.patch \ \ file://0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch \ file://0002-get_nscd_addresses-Fix-subscript-typos-BZ-29605.patch \