From patchwork Tue Jun 17 10:08:48 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: 65112 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 B00E2C71136 for ; Tue, 17 Jun 2025 10:09:30 +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.15269.1750154961827394090 for ; Tue, 17 Jun 2025 03:09: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=8263d137de=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 55H3t1EH005586 for ; Tue, 17 Jun 2025 10:09:21 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v5v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:20 +0000 (GMT) Received: from m0250812.ppops.net (m0250812.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA9K1a011535 for ; Tue, 17 Jun 2025 10:09:20 GMT Received: from nam02-bn1-obe.outbound.protection.outlook.com (mail-bn1nam02on2040.outbound.protection.outlook.com [40.107.212.40]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v5s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:20 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wVKX1BXmX0QdAmwYe/WCUAMx75gzZofWlcIXJqAwHM/Qa2FUeQWNaEveDhysHwvlrgyVCY3hOsbtfN51x3Kk8wNgMrxI5CzOkqesrin/kcV5A05LlPafyzruWCdpjKckAtw+2els0PZkFFbjHpSz4DNLE7tSnSIG3sa8001Hrybe2aEu42ISJBgZQ0ADN0fDGHqliVDpTAjPI330Fd+DQHM2Hdplx2ZKIGO4wJjbXFLlSt4MimdTpt6kAdC5BKm04p2hz3mGGj9DSw6y4XbYTm1NRoxfDR06uXZfRgO2WuXhyZ5JqqeVqjQUnNGmKUofVVigvvsPiR44WeteOPOtsw== 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=fmLyoFBAnq3r03WumrcanBTiQNM4nCC9vUqH0BekecE=; b=xtPzY5NWLyO9enVK4LhoL1Bcrex4eJsdSlvtrcvvsB+cY3ovLY5L9yYJCRbBQGvI9xh2tt/+a5MQOFV1+Ye2/IA0h2GiVcrlRqRGG+Y6M1ocaiMFY+drlt37D4jqlhag5filZD9QU7Fp0Ac5oXkedsH8zHtY709e6lVN5N8YQ0S9GenJ4jcz837bcjrj1aHzOAgtT5Vd7sSU3cqi0uZxR+KjgGnfUP1OkZ/5WWQV9esslRTknW8VydcFxpfQev6nZwpGa5mD3VMLJttEVKsZTpuMKRQGwSmh4wbMdnQAnPUwA/HqAFN40xXGB+zbsuW7ftmYSTZ9Xtvb7g2wMBYzZQ== 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 SJ0PR11MB4880.namprd11.prod.outlook.com (2603:10b6:a03:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun 2025 10:09:17 +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.027; Tue, 17 Jun 2025 10:09:17 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 1/8] glibc: pthreads NPTL lost wakeup fix 2 Date: Tue, 17 Jun 2025 03:08:48 -0700 Message-ID: <20250617100855.2696492-2-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ0PR11MB4880:EE_ X-MS-Office365-Filtering-Correlation-Id: b2f38377-09d5-4e25-5fb7-08ddad870530 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|52116014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: FSwRkXRQju0t3sulXu9n8aRBF3qt96FkmSYp/FLKRidN3Pxzs4Tk7BeMfDcd4RaIw+NGJYUuxizzC2lNt9X+LiZFsTp85q+En36dHmKgIDHKTE9XWygSxNEcb53OlHCVcSv0TwYh0GxHotSe7+YONw5LbxH/xrczK6O8LseciaHdojh3R6N6rskvb7DLb10jAgljNorxgndJ3lzy8+h0O+3Nu7DQ8Zfl/fkXWKfu475whLQb8OvZlMBESgI948WLTkfTKqzkP3f4uTxk9/IuFEh8KE5MIYVHNOrjE0ApKusu0gtLfLHhekmM90+1b8ljT6ybGSBFpwh1IkjvEE9OsCcwawmlk7G7XllA4lu2IEYpA7N0G3BrIjaeVYij8+MVhGqoqihDdMcAfEPwXn70e6627jWvOshqyiZu9/v2XybmCgoIu6yrIFwGflsGxcLy1zJ30SIcEhxArufSzrsTPBruij6To41Jtr5flJhZ1XgPy0i+TwtWYbpAVLXZ2WirpQZMehWmtVMYgS/wUnUxzKbVsGFEVmabxfCIGaR/mu2/QboF27Acy29BBsipDlvFPuCHCC+UG4I6xYejv+nFjt5wF14G6CUbyGr3lLm9B5huNoSrK4ngmSlP13fkEmSa/CkSszg4VMPEqH6YiF3+Qg3IRglmhZq5o4pyt4q0et1irgyOMBHGvUCGTcBZaEUSdsaP8gBhmkrBg+fNygku/auG/axEH5TQfH+Qb9L/mpR1exfvZ7ameL7IhNwlhRPQf4FmoRkw0RjSYMiAlRE+N4CaPJ/GunjLL2uZ8hxBFoe7A90n36+Cnmpm6RZZLvgV5B0nEa3ZSB08C8TwyA1Y9J0j4/ccVvq5i+tJORfpoZh8TA09/xfTdYEwB6buXjibmQ/SA8Tpa75Om0RaFM+BVYfSq7TiB2rNEr2g8SNwpdznPEXPa5dygOb12FtuT1w86gXXNid1VL6IeHhZ2xBHi/FZqFMBfFjeizj/IidUMunTV7/OKo1lZSI2d2h4FmhYH30jbrEEUoXzQ/4KxZJYNBCtiq24BjKuHG4yaX3Ask7JKIQ2kDsGV1V12iMiW+/49VPlra9eseUUlLXrK/zLB8qvpFBNitcC0/bhVPbUEtMj2dYwpkrfpKbNmrpOgiML6/uAgizorNz5FjSBfkQkODArEDFoSVuJbGXjnYJ2UEos8Ynf4FZUvTXzCWKRZDjljbMTMFCGX2MgyOTBeHBID13v64ClMyRCtPNvjVxJz3r2ClzyukoGAeO6TpW8WcW7+ha2ggYvwGitg6dbjFuixhGMZKLtiR8cv+Wpigyh+l9eJ7PeXcHr0O16qy/0xcoFHsiQ4U9hzFOIfNmS1EJkf2iKsiZGlcfKyq/jud84oGJ/Eq1MhpL2I6amRS2xWl0kngeT+gMoE2d2XO/4aG+edgPxqYYjEDdzEsPrL8A1PtenTtYdzkihJ+Vw9Ng0epuY 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)(366016)(1800799024)(376014)(52116014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: aKAj4zAUXUWSMYKpsbPUUoBx3fr3924XeGwM/Cdj7f3cEY9jhhl26OfcNPJapPMzJU+Kyf9yATLpt2IIgTMouoAJ9m7HLu+uv1TsOfRgaIkQ2iSHIh7/oH+5Ow4UPUIE9LRtFo/Jo7Bryct+j1xX8BFAxl10stDfpIVhHfTrJYsM8bnXK+OwNLhzBpepMTG+gorUDPFKsfz3KL1xnpfgh9wkdUI36NSqUmgOgFd97VB7t/g38FSzbqrN3uk2c1BSgDy6f45E2QEYEOoFE8po1zeEYFUqcVbb07LD3Jh48gZKqOMN3PVCOi0Onxl/v8jUzdyEbdQrKQ+fiOPfEBhI8qxID/t0/M6gLnqtLnlzXUYfTOFkO8vi1hJm0CEo9un1EB5w7qKRtX9iHOLheXI4VhePf8aOYNnMtD28rk/Wc1joBs7MPZsHLcNdkdsVMWgc5ds/aoYIEFKVAy22SlaKzs5rXjrkBRciCgPPEqAkMgX4boyixAngYtXO9VgTNLGbYdclccfWvVG6vuHVA1mNuHSjp8jy9/Eex3HmaH0tQus3MyqMSF/+CZcX9vIiirhKTU5F19h0a6bD1fOeUrt54nqfEK5znAZCxK7O8dvTFWV+t6tOJohFvifm2FoAqOv1aBQGApgxjnD2HsFJu+ZMnGn/4wlBsd1JmYHMpUoq2zgfHbhFh+JIyDVOigFQGAl5H2ymIAkuKEaTyurXP7cDGbDd6N/7nkYCoDOuIsyaQpt1rNvo4p+OaWbFzAiYchvrxq46D+jAQ8sgHdQCTMoJOflkvIaeysKIKmeAC9MyBYAQLOO4uoQsQj8d4WH4asXbUX1EbjHa7s5EfGClR7k/ppiljkolcVDzVSLyS4qs+G6zQ3lW4qrUKGN9GEvmhXi9879Rp17vqyOD8ZNduvy9cTyx0UfZa7rKQoE7Cp0Bgma4YJ1uICWoPFPc80v/JBSjW52x+Du2YKNWM9XsWbA4H7jTIof1KEIZNLJmNPxztnDLheYRaHp0A+RE5OwJKiOVmyPeKWG5GEgRsDat7Q+uLQT6sKZ7yWzevOub3nuUj4TuWd4AHsuBC5T5QSnw4l+u9eQw9hNF/f1ZRu+zE0RToupFKSUOhTXCBrwTf4h//us0gr5yGQQH6dUxYl3e/jyhk1pB+Js8DVqA+9lZ5MEwGSZacxLImcIc0ma3Gcl4r8AJB9l8rKSnqTVSvvNTMAV8LubrydbXca2lNAwK35ovo+n/c5iFC80yIhoFesXhxkklYtpRH3H7JL/RkorEZT4ceyT+GV5v7Dh4afFBqC70XfcnSiJL/zq1xRbNhv+aj0fVrxaxtVgMdFX08JftdLRm69sVGccmVeejKVvIy5P8A3qvEFP0lTfSChtmnL+CThAly5K9Zi/B52N87g3q9AnWgkI09MZ1hAMD1gsa/sGL0O0wV5z11lzUvxIaQjAPN9xUvGfi8ViUyNzI9rBmWNjSbCiRUxMAUmDoPPF6NY2aaMFnCrjwDfh3qhOg8I7EmLI8acGXnT4bCWodoSxO+BdBdFCWhaiCk3PUcIfqgANUSMrFlQ+w2tSg4tuRtm6c3ajwLTYd5ql2/hLg+Yoksm1BTi8z8iXJddGZaOp6r55UyGpXswqKU1o31AVe5b7pNEE= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2f38377-09d5-4e25-5fb7-08ddad870530 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:17.7103 (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: gH1wOjIdEBE9ZmUJdul8IjhxG/29vFX3VjRE/LDzka8EOfR8kAu+secFkP2PdRj0o44JGjw5asUZ/z4OjE+LnxWj0rZ9Sm+XvrKuD7RQUmg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4880 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfXwCNuFxX6uFsD PalQPP50tI+BhT/bi+vGQkK8q3YF9/8W09mF4d5w8h4olcOVzf1fhlMUX2ueSTCEunI5sWZhhWT 3rUpQF4QTk5+TtD+Ta7kgUiubDkVgGlVdIiMeW7hoWC0tSK4DPgrY8qIVVqXwYH30VUYwlE8UmO m5lpDWD914NJvMZ02gMfeBGyZPmlwdjWQSfCUxhVw/GVscbM7ofi1+nhzQ+xkt/sY/Vs9H9Ushg vka4r/bDCXN807mG79H4kIw7ExhdoLHUYpH4ZKaJEtYbwefj7MHAKEXyOjXCyfb/Wdw4JUljuHm hKbaLY6N2/BAec+mA7cAyk0xqAGwhucGDjTSu3Lg0vYpFwQsD9Oh1KqvYwl5jRYhoOQ1Qm6p4af hCNG6uXAFkQ3n3AGFbRd9PI2pBpnBE1IhOX4Yp6xm7mCDMUtJ9s5LyChdG4uvF33ES2j+2/3 X-Proofpoint-GUID: KK9efdXQXJNJiWSK-oLIKHSC5g35jNTV X-Authority-Analysis: v=2.4 cv=ar2yCTZV c=1 sm=1 tr=0 ts=68513ed0 cx=c_pps a=h+OmqRWQomUOPjbmtw9pcQ==: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-ORIG-GUID: NULJNSKRxX4mJZ4aFq0KEglPlu_gXMLr 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 impostorscore=0 clxscore=1015 bulkscore=0 adultscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:09:30 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218870 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=1db84775f831a1494993ce9c118deaf9537cc50a] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-1.patch | 455 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 456 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..44a2b6772c --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-1.patch @@ -0,0 +1,455 @@ +From 31d9848830e496f57d4182b518467c4c63bfd4bd Mon Sep 17 00:00:00 2001 +From: Frank Barrus +Date: Mon, 16 Jun 2025 22:37:54 -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 +[https://sourceware.org/git/?p=glibc.git;a=commit;h=1db84775f831a1494993ce9c118deaf9537cc50a] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_common.c | 106 +++++++++------------------ + nptl/pthread_cond_wait.c | 144 ++++++++++++------------------------- + 2 files changed, 81 insertions(+), 169 deletions(-) + +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index fb035f72c3..8dd7037923 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,85 +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 + noticing that __g1_start is larger. +@@ -311,6 +271,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 20c348a503..1cb3dbf7b0 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 Tue Jun 17 10:08:49 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: 65114 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 AB073C7115A for ; Tue, 17 Jun 2025 10:09:40 +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.15139.1750154970924259913 for ; Tue, 17 Jun 2025 03:09:31 -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=8263d137de=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 55H879X1023515 for ; Tue, 17 Jun 2025 10:09:30 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:29 +0000 (GMT) Received: from m0250812.ppops.net (m0250812.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA9Tob011655 for ; Tue, 17 Jun 2025 10:09:29 GMT Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02on2089.outbound.protection.outlook.com [40.107.96.89]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v6e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:29 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qei2KbGwtISDIqLiLBOa02tqgpnTt12axOWvsaKllZJYeo6E2M86fwfNvPegPAX4K5Um3OvXx1aUpq4EfA51koQCmCLRfhJspdjokWTC9PI4WJA0eoP6wxWxViNS8GG/4WvD+opPL6hYXve4BRMwWHNbIJBVSo1fk8og4KUjPsEDFrF2uvA0sClrq/BDyZmBXigmiiRIhpk/eKc/PMlvi7DOYrV1kFieLkhNZyDw0cBhQQmTivhw3FthYADpovzqMHHWQWRxzk9moxMx1gOPpOW9EdqeREwrxzhiTfm2SJzLfmAj7DcCXSBcfPAI9DPcMi7sUAAvv5VpiC6ROlvenQ== 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=jIQTQuFP1qraw9HcAdRZ3E0nKJvjZ9wSguf5EwjdMrI=; b=ppMPgE6/vKU3T3SsM8xsmWEsyYAxh08NDtRw9viT9JVyVQslFiKjqqmc5I9aiNVJd76sq2h18XW+NLBxcMcHoU7RsQM5AxPPjHhEFMxWlZqsITQoO46i2wf7IcXB/dhP3SBSAARqbFPrLxmr62SSwafbJs6708hZ7MigQSslnx7pvUBgjAAHEhCGOAamRzoBJaQ4dvEe5mw+8LHSMTU3vJKgJJ1MIESnJs94CqFteDXVnGHucRwXF3ptn5MxyMk2Kofe9RNqkL5roS1+GMA7B53AIVI4124Cixou6MlNyvMhdmZ3DT6L2NzcXx1oEdZBJ/Phcdjv+ko4pVpr4ZyYWw== 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 SJ0PR11MB4880.namprd11.prod.outlook.com (2603:10b6:a03:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun 2025 10:09:27 +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.027; Tue, 17 Jun 2025 10:09:27 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 2/8] glibc: nptl Update comments and indentation for new condvar implementation Date: Tue, 17 Jun 2025 03:08:49 -0700 Message-ID: <20250617100855.2696492-3-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ0PR11MB4880:EE_ X-MS-Office365-Filtering-Correlation-Id: 3f04aeb8-6ece-4310-01ce-08ddad870ad2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|52116014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: 2d4oGMB6220fbx/vwQUxIgaBwKeW/wPfRZpY74zFcxYmaMpNEZLKhbpEQ8ncddFTajwltnKyU5ypOHvSUu2g50pSSi3HXmOxlEhpyjxtHcrCc979Tn0XpZ8rBIlyvuS49RI8OXJGH2ejzB1uZt/CWwi0wLHfhtXnk4n3m2YFhgGOU0wvYlRiNl2WHkgbRgSXK2sZTL9c+QBB93ISCdnu5gIPsd/WYgcjTeg9YW4EIlOjiji3q9svgfbFcvNsAxssdUbTK+kKwLlR5sCQWXtZg4sb2MKV0pd14TeuEKEJkQgO86/1RHTEX+u1Di8ZlUk6k/qkJhRxBbwDsWEI/640TvhL59CTFBbmwY4kwgaRvSFnrgBfjZOLCH8i4rZ3wwzrsm8+LIEBOcauIk2B6m/zaxO76N6Uj3sVOkecsnVsfaDQ06kMxubaJmYsUcsb8KQasOKz67loAkW9elFIQfDp6bZ+kJkViCboC2vEKFJD7H1Y7/yWoBSNlNDHQ2zQIpq5KU5laji2CPwQoEEYeehP/xrhnW2u6xZPsN0crcqvHd/NNxevYd0zZ9ZAJeVf6uJ87GyWbgv9jDLTlhYvkZ47kphPKOuXXxxX+rJBjg21glkjEYl1fouMVBjeO5D89m4eLuD0E1IetBD+b27yfoA9dd8bWwzz4ioHmZTaDtQ7N38oRDgyUu2wj7QIQOPxD5VpsVyjK4sYwNq6rg9H3/C0NktsODytGftBKyOQfCaWbSenmcX9ERuQVATVRQo2hu4+bCLGU7enRTy4f4aYTiOhNz3xtc7BVAZBLfD/ZNsztITqApED0Lf0ocs3GHKm4MnplRr6osuRvdi6P8W5uc7rOI4YsmDiBdOngZ4rM3HsQ0JWyrw1TJJ+d1FzV2L4ioouVASfoKpeE5JtqSkKkxS7W/hd7tF8vnxYlYHjhyViM8xZr94vhSY86eF0u/tiWaUKIFqgZzoScmWMdTQMfnhCCIrSriQ6Lwu/XIZU6KrFD52z0AjajgS+mSbibHehWUFyFFLX/pYsLfGG5Q7vBQvBPjYucyg7C9g50vLksNeLaSbPibkSWpMxwj61MlMja1zHL5tgbuomY+FtOzADRD9umj6dGqHu0o+FJKIKhQQm1EH5CMEPvC/XhJXIWiVfe5VUKPy0jHKLqZZPjiJYO0eIPHiKiDKmoKWc5MZ4WtJ6HTHtY0fTj5nhKfUv8Uy0oYEmglXTIKw/m/P+SXYS1lIoZfbruYaB0y0hv2jX9SAO2qD5Ry8uh06bmTFVvPKXEHI0HqhNudqWgQ2bA/kVyJV2dTY8gQPn9kDTfzFLVk1huSrpoBnbv0C7k3fqDnQmB3hF9Iu2R3jO1lHrNhC7EEIZI4NfI/vq2IX2jsGZCJD0iEd/oRjF4H2WMcaKBS2AQ2eAfOuxZA4usweeBQt+V7epsaI/A+cPvcFr44uFIDPT27EMAcsBjm3WacqtBf7CZbNC 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)(366016)(1800799024)(376014)(52116014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: J81L1ja8IHMqtOSxRU4sZ0BKlkgN37BEMn6C845KsSL5EwxM+TML++nnJWD1K79erGuDRKgxuEDVEC7xjJISOJy/5Ef2OyCaLSEfMoDGJzwH8V2BY8xm8xTc7xmkArAvaqEJn4QNCRwTSVwh+IKr4LHhoKf3S62ECrC9L+smuuVQz0t9X4c6yG+hx0Wh/8lo4/VVYxoy3qHbTkpnUO8sWYeKx9TwdcAKvKj6oIXSS4bOcebW+wLJX3/zyUaNo+asSDNInli7+h8OD9Dl+UZ1asOZNJMKkZKibgIlecfO7QjIVat/DyE/SxAEaoIXLbxK0hhxDhVVkIfVcp04JA5z+GDkiJaEOd7SV/jb/XD/upwa3u5sGQMwc4/7cr7RW1RZOy2Gzqd4S+SG2cmwpI8rdFFhl8a24x6JZHKo1T/cgy5l8b+21hdlkXQdQIbObZSSFevdDl7iQUDHuaF/b1Z3Ei29+Yb0TsHSzaP/5XrNWfEhTvCVxxXccqlzwCfWZawVS7/tewn1XyUfjR+wykMiWTfQqVNwqXnLLz56zSH5gWU4QPWTvnDXlylWWzt8JZGGFZKj7eExpEHB/K6vs0PehFUW7vmKNhe5wNI8Xv1kixHfROhmhh80S5nMa52iASEdwwOBNb8kT4me/Y5l6hfXaOIAkAkLLC87CGKvl5fVWaW4VT9EWjMc9k+/TKrhPNz+g8TTniZy44PolGiuFABTugAmqcahgffyL40uqudl2QOgbsBKiuP6Se3UeBeirAbAH/O4NjUvKH514NVZZZnwVHWli/C2VtyNknKwbdsY9Ogn7s94ut1EMz1KZJmYvEMIFu827Qr+HX21Rvk2nCFfsj8K0l5TgiGIpRMjDQs5+9ARPCZu1Vkt5EHQuPhIplbvcw/SjvDc0chn+kYSP/9Zu1sCIbnvTACwZbROF+2+Ba2FH9+Jg1/W8f3DhirI1A0yyrxZ6/gBBrZZJWmScYz1JFbFcA/FC+TXCYNcGOGqOTzq0wpH4GH9xAoTVRw32SOdIVKTwflMIZf4C+AmN7GInL3hAufZieDhlo2hfN2MgziW+sLhBvDc2RA2eC3oWxHJgtbXuU/dt/L/aYPJF6fQTlsMa/Fpo3h2ULIreFM775p1un3rPayO8ndh67t1YPjTrq4LvrzVBJGS1fio8I1MIcmb5bWAA85yUmL0aWJ6RuOFPc8C6QEHsnsEQY2ZH0u15SrNgkjtnqv7ij4zeEAgGnYNnROJLxWJcqOPwq75DwoicrLFIG9jDhkiasUmMK0Nf3rQFrc+RAL+MoY6PnLl7aCE518cE3Mu8oHtfLz1tdMDvGRI+a3I0YdPigEHOvtk3AZspgzFScQESByV9LSXPOr4GiwpHVVyjKwGslNFVFoGCgBOcE/espuVWVrXReYAxZIdRdC+EHqjzapCgVU/ktKobQbMPtyGht9iKUMeKat6vQmck6Kzs0cgPZ+pn9/FjdqQrQ0BLQtuqs/MXZ7eH3DcY/fiLfB1+/1j8MGg6CWwReM3V/47cs8+Ba7ku50DS1k3LrI+p92WUontoyPY7PUqpRDLAFnEiGqnP8uVzXLDtFfoSk3jsO0CUBpciTcagRHkRUWWGiBV0QjEII7PY3Rb/ohcoI2XRGYNbgXIgUU= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f04aeb8-6ece-4310-01ce-08ddad870ad2 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:27.1561 (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: HbF0eEKqwkGGMRA7Xf4WGLTKXf2wM3PXyGrQJu54ax78QPtvORStjPhWSX5gJoDtBoo8A6ran2nHbyFL6ILc84cjinRfb8JJN2bCaPxhHJo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4880 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfX1mzzanDDyFL6 eoBRdXGMM08MSSyWXMZj2jO56o578uSKtZRUsSqMbljbWkejV7KBn8geL/3uzZUyJH1X2wViIFW sVQS22l7IUKcCHOkIrDtlXJ7403rHYZguxRaXGfGe33fHbsEpBUyNDqlzzO5PvS6D8CFFaXWavD 0kgRpTeiKdhaRcIdR+MAZaONfw7z8TNoH7d9Zd/tcMayi6/ZiVQ/J70jVMKjFAHa8/eB93Uxu04 mQ9ieNm6dU38ROjrk+hM76/ZYACoslHDwqFZHBrK706YlE0NiTLaDH8dEfiZpXux1LTTJrvZ7Oq XiQW+oU3KaQ1xIgoLRwE0mjFfEppcMgOV3TWt0RMZmKzdZg4T0FOVc3l97w8W1/YVNGRJqQr9lF J8ZK4mS3yHnQRm5yLVEW/WmOsQH8OKadHpU5kgKEyGn/YyYXsK/OdMhdMrm/6Y3X6nqSZfXP X-Proofpoint-GUID: g_TGsLGZO5VRPM0qn8_ImwxMcXvVCs41 X-Authority-Analysis: v=2.4 cv=ar2yCTZV c=1 sm=1 tr=0 ts=68513ed9 cx=c_pps a=9C35tCqyHM+r0tyiOoHRTA==: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-ORIG-GUID: sZWn4CyZXbfzv70U4yWWnhuUHe2dAo_p 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 impostorscore=0 clxscore=1015 bulkscore=0 adultscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:09:40 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218871 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=0cc973160c23bb67f895bc887dd6942d29f8fee3] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-2.patch | 144 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 145 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..cb89431769 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-2.patch @@ -0,0 +1,144 @@ +From 6aab1191e35a3da66e8c49d95178a9d77c119a1f Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 16 Jun 2025 23:17:53 -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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=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 8dd7037923..306a207dd6 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 1cb3dbf7b0..cee1968756 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 Tue Jun 17 10:08:50 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: 65113 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 AB03BC71136 for ; Tue, 17 Jun 2025 10:09:40 +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.15274.1750154975293492897 for ; Tue, 17 Jun 2025 03:09:35 -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=8263d137de=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 55H7k1qt023920 for ; Tue, 17 Jun 2025 10:09:34 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v76-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:34 +0000 (GMT) Received: from m0250812.ppops.net (m0250812.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA9X0l011812 for ; Tue, 17 Jun 2025 10:09:33 GMT Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02on2048.outbound.protection.outlook.com [40.107.95.48]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v71-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:33 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u881MpILtHJGrv+0Byu+XtjNL13NTp9HYCrFNu/H+3eXg8Wp+gaNNXwjI6bwaRluSS5j+Wjf7NApMv3YPfFRxeY9MZxxIgTjAzotiq+MF5s8nDuV6KgEhafZQaw0TOK+BuX2RrjyPiQHx0iVmStw265N70zLqTIJVVMHr9oWVRoe5px/9jQoPwiHzu259jLIEMx0YUQgutBuu+1FDoS7aWFVUJRFWpC7rlXAPy4KpmfjYC1hmkB+Xip1ntOCHC8RnQrg9CP3xDmX+MUhhs96q1vnw185tcFzFfAWZR9cnFuoERLLDw39rcfaH5xLCJvNpu7QIvJ7f2JxJ02bmFbj9A== 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=TGhpq9oD5ez7U8Ejn/rhFhEi1SGvVE8kU1bLaTKI8TM=; b=kUiQLsB5rjitOZ/IfeoxQjUiPEbs4Yg3QrNQi82P7fANVGitc89PuQ+tfAttzjl0Y07tXReCMIt3oPfnGnw1XGuVqEuGVhw4vIlXA8IzldXMZmvPzPKJmCIJtJHiOhjxwmUw0B7QnIUDbM7r3lv3gn5XzvVpfS2elmb2tZT9yj2elvVvEoxka9i1ACcwe2PUlynmqG3b2pOLIGGi/dt+ssYeNRqjq8yHKQqze+O0Bh+k8xxR/vZJ1wBGUoI7k85LbjKnfjJv2h14dqd4/Znr39h2R+5pieGwqJ9M/LpzJDIHD+mh7jsSUzlGfsQjW7ViT4qOOxUhVxWZdN05q0Fmfw== 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 SJ0PR11MB4880.namprd11.prod.outlook.com (2603:10b6:a03:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun 2025 10:09:32 +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.027; Tue, 17 Jun 2025 10:09:32 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 3/8] glibc: nptl Remove unnecessary catch-all-wake in condvar group switch Date: Tue, 17 Jun 2025 03:08:50 -0700 Message-ID: <20250617100855.2696492-4-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ0PR11MB4880:EE_ X-MS-Office365-Filtering-Correlation-Id: 709fe438-0c9f-4f3e-9262-08ddad870da9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|52116014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: i6HHVFf1RlS73Xw5thYEbvvAHjx9yKiNW01mJ6rFwWG6RS+Z3ngQvC+fiK4+dPFvlG1asdl4xnFuPOGibIueq5KxwCP84lniluSukRJYeL5nwpkLAXBw/cni/zwa+2E4P25zxKISlmLml8tPRLVK4nobFsnJvONK2KdkqbTLLjW6C4HYPO0f+K3dIlsnZVQQTpK5PPKgvckLf4LnatXelxkRDUc1Xavc8O+cInh1BJXG/SBJggKdxhcA4fPfhhhIxRDkRBDtI03/ai/i/azGteoMnnDuOgEyF1//zE1JcYd1FXs6B3BPsrg6rInAB/VCdww5VdBC4GJbJCjXeUdqB56DMIHo77mVM9NdX06Tru0uKmZjZFqUxdb/ulhquNkzXRUB6nWMgxMKKaxBeXt/Ek84+8I5zpA/4/2QIqQYuo1RTgY5DdEM6PawbT8nZaL/l9+5z9RjzgYzZ5Oi64WxGDQ2IFEJg/LFSHx86cSHP7M+Q3Cjrj11dPBuTPj7icVLAcirfEQrG2pQd+LXmEBXRAnoHZ3sjtbpEqVOH9oEp7bqBkgMz1ucVl1N5LAjekDGdNxWUIaHHvM+xwOHAB16dCXcf5lgdK8V01GRHZT1QBAmwdWOHagU1nQtK3BpKMhpVwtiRSoTfp0kAIGxfo1A1DG264x6g1c9zOKmXaxH6l+jYFHU3hC6/S/pxVjH7nAeBlN+tueFr/eDmCucOWZvstzgnpep99bB1KdaT33FZaoy7E+G0LiVu7S2vG5zYGTwFmPOXz2szkMHif/EljDmXFLV4dSrkvKt+jRYevehNkYx1R7pLY6sqnGtT6HmDVKkbQDxyqQbZkyaz9kmM0Kb4gc0EMjR4d2yCBNUnrSseiYhmn5CFiLZAPIcGuaWXLOBuTx9ABzm6JtRNeqOFLdZyebvU8XPUnYaEy7vvWfSyKgREVH/0s+B5Imtc2HuW0qZIbjygYB2yorwbRvnbE7J8AF7J1x8TJ2DpZf9Jn/olIxpdxrYpyC33Hh2pbK9yYYXGfqZ4JJTlKi5IIyDX15EEel9GDdYFdr3d/+K3Z8p+WNwsRZIrWudcoK+HvCT4/iWSTKVTsvr+9f4E+0zVW7s46tLqARQCeaey9O59xahD3Vgm40ZRDiZHQ5vuQbNHmirW8zmdfopA0dhNUnMaFh0vtdktOT7yMKuymnW2COTLvqqGJrI5YuXOL7aCWDzVoCkFIOZ14ZwN+seb8ek4JeBp5sIZWt3hJReTcKZuw1IQqWrKr14GDac49O1xFoz54OC0jHx2WRm3gT3hTrL9tjgu1sP8NCL2PqrIiQ326aBVHftgYXbHci3mFivcwItZlQL/bkjYkkntbJ1kA5X/3Z9IJ8i0Xftum2h5X/woLp2BJT98TT56XBkVUldkFq9pOzQKI/LHqrjn7e6GZF4S2ixfJuc0tY4FfPaMnaSSUsnhDxvlHfWDY4wbV+YS+C2F3Dq 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)(366016)(1800799024)(376014)(52116014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EPgtxg+aaMV9z9ScLzIy0DGcgzjx6PamoHchtUIKNd2P6u09BTMuDSM6znwWvY48FVLX+WzSYQ9NZD1tU4sjRqJxXntV6jCmyp95xc8EB6Mhhrn4k/VslMqPdMrswrO6rhcxK9pwU991jenrc+2rpyruscxo3BKQiofMUZXXzKeJLnfKGndvMR2hAlVVHBKop3kQ8Bw4GSRAHdfFuLLa2g+D4rUpOeSs0iJYGSCzGdLl7VxIQHxC/TkXGIiwIo7WcEEvVUD78UjoUiVLvDs91skZoAzGIYtgNIxBypZSQyxfkkedo0lQ0fV8SwL00CvST+QUOh9vSBdw9SkeuE/J6TfiUVAgmhd2t8Ezto2YdzIlQa77et25NAsVmgJKBTP8P9TlN3VTeGfENyK4vaILaqy5LcL5HZumQ9kYXGzq0MvDKi9exE82+xXIOQjC9S4EcJsLTpFhlCV/Ikd5ngyk8Tnel+TrKdSz9wgBuaAwb2j08HrtN/HiK6Xy7a0Tj6XR4iIuCO6kerBDKiKWj31iHq++MnHDuledB5oG77uepfVBgkiBy6vPtmRzC2IVmjhYNFGdg2akTL/oiiMxwOVQfawC+VH61VrJMjiNmrrx3RfbkbHJXONJkxDL+fz0tHbRd+y4hQIo+up0lBGg2GmVIvRymUjRqOQQV5xFxIIIjOZYR7N55oqdnTqTyeW01Pc11Hu9fEunxqJlDHOEkzPdzYREY5jjrMyebQqa4JARHXfie7Kxa5ktBnXbEvq2r0bTLYp0dslAIC7602kRtzhNEdh48cuRglK5zFxsxxhdWpdpxd3JyNJmgRNYZzrd/xl/xQN9wfjc+c7bWwS7Hk2ckZPLZQWw61lHiTkiLp7rGFk191f97SoRg7NHCo9o92a/svi5Jj6XoA2WFTbqn4cMWXBABsLBlPz86ISzXw+eb0Et1TcF5n0y3DmMQaVd0n3UXbo9BJ3MZgIu9D7qs0VwpwsSXP+LJgQzzdGbjK2+f8HBPzoV0PBH554uCtcZ84Qut8lvJu1rSUPRacy4VwQ/+Jo7hoUtOUlgbMcVAXBDcvLbO9UkfPiUPNYcR6NOOCzz08ocnDMaq+OP3Gh4QAALTUV84VhdBEUxIyOC7MS93pANl0rzYdUTAvKK4tFYsTNnwJVjIizWY132Nhhbula47+JIze3CAaoN+qkIfA/w9WQBl0Pf8fiSOKNMSVTWIeDF8kT2dhTZ80WvLGQB07i00reazZ7uDDwYF/hqN8nDzxxNLdycttD5WjlfyjwFaWxQotuiqD4YWmmqr5fNCQphcFRGwPWjXmZZhJcG5cGK63v6c03QHk1HdpnIp2Trjmu6oDQDoomX7os51KY4Y5acVUU0xXWzQfK4mazZiIoHpRTYSyuDLAFa5byaq9Aeo0FBwlhx9aBhgAUHy2/uwkUFQPRQDn1hxAlwvMkXmUTUYd0xgMeiOoq207bNlxNI+FXF8IOi6BXjBlYNGzIlTtsMU42cj0KQg5UhaYJbOOp+saY+oIAnYC0jw+iGNS+9sI1kFj5e+BLrC4Ok77v++5SwTr5iU0tGPmaSfOAEiBWb1jZCJ2475Lj4W+KqjLQI5QKn1MFR/v+LwQmWouCZkRIRTw== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 709fe438-0c9f-4f3e-9262-08ddad870da9 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:31.9264 (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: ktpyr2z+n7vv6jBoanvMMU7GW/4V1gQ4HbuRSbsGSGWZ6fWya9EH9AiNvHumDjX6xasU0K3XsUZXSGrj290ncMYSOB4VTN9vSIAoOzilP0E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4880 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfX6YCDrPgH8Tui 5VmsbvisVX/jpXQZw9218ogS/DD0j1bjB/zcZgrDc5wtoLDhi1RIRq0GPyW70wN6WlT/Dbn/x+g ABcXgVS6Hr/UIOJ2OIT70DuJq8X2R0XIWzbwvdboWWzpJBh4Lmm6tBEFknCrWpagK4v0ZRtq4dk kFj3E+fPCrR3PAvBgqTPSwzvBA5aL88aw2sQu8wXh9RvYuenwYrqvhC2httK5+hk26hVkDSSlTP 1Gbc0BGYQpyoSarn8gmFyvKrQ4/Yt+nrcfXjYyfdmSOGQuoviGrzwxgPGq9UQhopZXJlamtL+3G qpqtr5RQmbksWs+z16AEKOGWfzLZdA52eUBWx1yrs39XGabWU3ShvtLthU5ihygV/2KdsluAjYG DMTaovRuL4T5sPktXX0S4voYZDV++cL/h7QTvdVAY6cdV3QHv71dLNyZmBwcMk9TyMgMGrHs X-Proofpoint-GUID: vLXvef3h4yjA1sVjivBHUTE4pnOLjhbn X-Authority-Analysis: v=2.4 cv=ar2yCTZV c=1 sm=1 tr=0 ts=68513ede cx=c_pps a=9MCiTn2FFLWeZXu3Q3AfBg==: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-ORIG-GUID: nmFHpwkgwfYDA5fJXP8nxLskCnfDVdk7 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 impostorscore=0 clxscore=1015 bulkscore=0 adultscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:09:40 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218872 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=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..4cfcca846c --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-3.patch @@ -0,0 +1,77 @@ +From 28a5082045429fdc5a4744d45fdc5b5202528eaa Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 16 Jun 2025 23:29:49 -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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=b42cc6af11062c260c7dfa91f1c89891366fed3e] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_common.c | 30 +----------------------------- + 1 file changed, 1 insertion(+), 29 deletions(-) + +diff --git a/nptl/pthread_cond_common.c b/nptl/pthread_cond_common.c +index 306a207dd6..f976a533a1 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,28 +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 Tue Jun 17 10:08:51 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: 65116 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 A6E95C71157 for ; Tue, 17 Jun 2025 10:09:50 +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.15141.1750154980545481681 for ; Tue, 17 Jun 2025 03:09:40 -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=8263d137de=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 55H3t1EO005586 for ; Tue, 17 Jun 2025 10:09:39 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v7r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:39 +0000 (GMT) Received: from m0250812.ppops.net (m0250812.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA9TuO011721 for ; Tue, 17 Jun 2025 10:09:39 GMT Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02on2084.outbound.protection.outlook.com [40.107.96.84]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4790282v7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:39 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XJ5AMjM9C+kHVSSKJyWRKCOzZFrifVeIyl3hqVkJyCXCXlXJer9If0bqpS8DFzElq3ciPwSlzdr5RMwhBHYJgzUIPlKwGV2BLPeog6rO7CkoSfFS1Wkp7HsIidnuBeQSdtOiGh02cjhB9riI3XhlG6zYzzypdwqQ5ddlNQiPzq/8GObPmL/V1Ch6ypHG6mTB31BXTLtsmt6oFhcmMo6/IlCJNlyEI85Q9rwGp1JXHmUdtwgNVHwgpIVYRxrhUvqXTwwiB99SuoNX2Hkt0ZzQdCxD5/pWsXk0ytVgkSYzweLS71aYSM1DXPHLxOzxwd08DNADFm4p0rT4QKBVIqklBw== 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=SRGy5BLbWzfSNap+3dtLjsH2PZ5RXxwnuSh+2mN9ZnU=; b=ukhGTYeC9BFYWmkkwR//3A0G+66VCWVnL856QvFWCOwwoS33WksL7pTnjLw+ttsHNfGYDc3opds7wr+WiHyzUv2ID6WL8EHTQTQQl7CkP3po0TgS7LJboj5Fw0gZQ23f2EuCT2InNMwsCI6Ln91rRSF/i2Bk3aBtK26QNe3TYFgIwKLe+1T/AL3amp7KP8jJTRl9H71T56LBQEGIDxudsciSDxSWfi6GmlaRek+MH4vqZIfitOUbKhCb3Gdtyw9VH1F4LJTeOp0op9QvDuxuFEpM1t86v2ib21BtZe8AP1Z7v7n8RIozMYvcD6L2oMKTI4nirYzHdrrveHPWk8hJLw== 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 SJ0PR11MB4880.namprd11.prod.outlook.com (2603:10b6:a03:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun 2025 10:09:37 +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.027; Tue, 17 Jun 2025 10:09:36 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 4/8] glibc: nptl Remove unnecessary quadruple check in pthread_cond_wait Date: Tue, 17 Jun 2025 03:08:51 -0700 Message-ID: <20250617100855.2696492-5-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ0PR11MB4880:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c245926-8058-411b-c928-08ddad871082 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|52116014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: laiBRGQAg+kweHOAzbUBs2lx2qQaxghWKrAACqjDQ8S/SsahFD+cfT1is3lqo5TUpcKQTRg50FTzp1qyEThCYx8F2rKMaEZu8YhWyif8aZSIQqaZc/yQvNTHKUbYHPKiwFr0+fwhgN1XNAolX9ruo28z1nr5wMfp1EgniuYDi3mbt6I/zBorracVbqklrE+nGWasnrTefwqrCn3LVmhQxSeqL7fphXShvF38/lWc+REy9yFShORWVbAbRZz5dy0VdBJ8TPHvXh4vtDM0E748EFgWniB2GiIa2wmt2Ep0DdeqWRlixXoTRr7p/tUhbDETw+atdyLXm6PfODn8jNzihThKM9UBvul0iccj+b4a0vrmmJwheKNqkoPC2RL1U9N59P7fxBxRPEOnMlTMLwHS7+lJFNEvVx6QYt+esxUlwz2xTRCeZD7XkX5Z25qdnzIZ5nNvFX+QjOHWUswbw5vpDLk8cAnoNe2t2UQQo2q1Bvo3dPHGp8g2knRlxyuiN0zaXaHTXVNBczUZ77Zb4huBP3c2rF3BMez07ISW2Qq34SYCKJfSNK2+gK2qaY8FavE0OVjvsoBJm/FjJskdbeHJaoDjlR6mSh+ZLO7DxkKCvJBEn7tSdJcJInyAiIYG7tQJ+iCmJy9CPdPkvaA8poVDBQXNMRdqkzwSWzG9h8kaoENW6xYs5Vl2W3PdjvNgIhjA1K9BgGASy7EwFQgFmhBF8d69Cs0hYbhTNxJx/SNmoPwSuVtL1vx0zNyt6rkve7spFUF+QzCH0OlloXJdH+LXIdJuhhY7i5Lqkdv0XeTClaQLPAariFPFr9nlakv01NyjUQzofOwzI85dUdtMAljKqn7pwwmSEA5iTP9angsS/w6xeq1NecpUXDkWdyVwPN8kKFU0floFX3u+7ccb6lHfd9Crl6Ob7h5c01zMF5azv6uDq+zQ450IdwGWV1ox5Uya6ClLaYzGqAKW3vBsPNMcS3hb5v2RJpwTDrhcKAJjW7GfrtpEG7kUMdipEVkUozFv5e/uGvtsJ7yy+tNYbP+KSPfhcZWHN7MxEBxMF0YRBHoty0gjwuG2cGScbhvle3qXi3Y0oL4QeihtG3ozNp2KrNyuu61zsa5mjTauOjoFoZ7s8RVwkkoQif1EfGBkVD/liMzqilJRJW2mAZ5lRT/egiKp1IcyWvNVT9eSm5PLe5SzMK6NSb+XyP/rnZAZIV7gsnZtbiMljEVkDh+rD8QXJZVPedG90RlQquVAEGJ1fcY0XHFlaBqG27FvbiOfFtyRNg0iFbV8fLnCdrijiX73JNZV3fDeawXq9N9xuF63xKdOq9+t27aQ2vzkKILedOhGwLS+4oD7WbjEHr/l+qIodT6yBKXgr7cSuh13uvmPJ6/IwrrKJ6zAZ9uWn+9zogeYkHn0PV5DGfUqRS8QNMQZGGzRe6Nn0YjN7Qt9AAcvXi/rlIERi1zuiJf1zZGnRZf6 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)(366016)(1800799024)(376014)(52116014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WHsRW+8ftOdyLguc4UVsVefw2MylD70Rcxehg6odo0kCG1DOO9uOLWfgPirCpK+OeJxXZ/fNIj81qWnvycI2tsTFLM9ARDp/WdrhQHV+5T+MtURQOV9orIiJcvixyNPDKdRW96D4dnM9La9Soku8ItAH/VDAdeBhZzGLeApU5tu3hHqDyYFkRY7OVRbfVS2gtxTxtYr4Ay6plIfcvdFxlpJ0TYOZj3PfeBPGS02rV/MuPdUEYAXOJrwoOpcy9CMFgsXcdpN8I5Afh/z+UxlrhOytN7GXncHk9b5HGJyEpKIUl2+mKkW5eq/AKUTvUzDQc7EN3zIusHoQwONbGkHzmUTQFFz2nJqtZPd0obG8TmgAwZaq1U2+jevElLOj0OAJ9xXAHF1ioTNqorqHqShJu52SEh+Ar7ybR9CyNSoY7QyAxqvrHCX7mi3Um1QqK3/SjypiJrUnSH6ELyCBSYlbw7S08+s1ptyBuHSaVdqQNw4hHBm/bvy37AZhFPY/rqc7wnezlf4Wk+iVhTFumXEqeaC6ZQ8esYxT+qDEhJBOOoANmqMjP/ZXUf+o4GgGiNGlpuD/Dfq2LUsu1Pbmm8BMX9bsF92MGirYhmBWUrZ6k7P53fwAw0NrzXaWuv+Ipog4aPTLxEw01koBv0s5fd/+Bvf6XGM4Euer3UbD5lufrSyF7xnBPCJBN8s+vbZbXZNiw/Aid3DywWcwhdLt9DgF7K2aP+aVGVbBuOjexYpNuW7CwxDt0ZL6e2V49HGph1UzAi7FAfyACAA1Y7wIx9tt91oN7fpczEYZxd1+vEJOZgj3RsplIM0l991YgNdtJWpxK/dp+NRjC/oRq5PBFnuHCYpO/SoTVwsxnfju5G8iV/RmaumlPFeActFEyk2m7MdRps/VezP6cwL18IQkzFjCNMLlEeVlHw4pIthUkwW32oRo7AwDsRZLSgQBmsFwIieiSQIBkU3hXTOHVpQC0NEfytaGZACGhAbaZzF/Y77rkEiMr06Afpieo30sjj6I9qpcl+gZ2KPLlQT7E/LJdrvgo26oU+7h1oHzKE3BypyKz4/ELXst4+WWaD36Rgax5oGQ5oF0R+W0fGNPcwNr7sQuo3g+EHOe1bjDxDEGy07ElfZzzzf6hgucckBvegnHRQfFxY4wf4mh8xDRLoCNvBuhatQEoQ3uiYmPTcBkPZivrQr/5BD8FjVPX3JjWWxdomcIkNOr2JzM809UR1wo4d0IUzDnOjadFe/bPvAD750O8PiCKdtIRHS/2LE+bfq6hMQxneI6vKomaQqW0nBzB95apLWaiSUSNU0TowYpGVEsjx21xZfOFj71im97+wZOEbVFG3jgUWd2c17je0DACYcdSfVdS+mpXMvJDejhXtf5iz+Vsax1ZSYrZqnyxpKUH9fDalY9+y4+SJzTklNiqHfsZyEpEjHYWd70929VvHC13Lqf56VI9e75wUe+kL4BD3iuH6sP/v2xkzaHFZUJOGAZPooWSxtCQ7jusc0UkeX+T428oUa4OEtohOVf1BsiWUS2CnbR0vD0hRfFcAKwqzwy7y0yaDtjmS9duLLUyePfQAGaF1V+PH31LSxiOQ0AJzGoUH8TRg+XMNGt5/JkJP7iTw== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c245926-8058-411b-c928-08ddad871082 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:36.7058 (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: genNSTRwejklyZdLBD5L90Bbk3jcb3KwmGydpuAERfcZOVpigYpgu1rFma6EYL9Gk47A7peQSwzIWANKp5dPaRMGSeVVy3Ba54rcdz2FV/o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4880 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfXyryX9wHqBFdL rNCQMTw3bYNzwtjzwsw9znmCxKdc19nmzpydBoUlJCgakAe8RdPeZaMjfr181H29KRCVCREd00R nadb0r0gWgX6BU1+DeK2jAKcLo9ROQqFYUycTr/CinZx9TUM6PZ1obCi7iHyMMiZVVtkCuLVN04 lRPXlRVE9t17OvScMDSuOoSyqkHm3/GhUN70Eak/4RDib5lZfr515+1g/Hw9yKiR6EibiVWJigf 95iXjvXI0tgNamM/sCzowAUo3ueHI0AfxDZ7x0CD0acUCL0HLZH8NfWlvD9x6Izsx9qblZSwi2Q I6j5PdMiW3NYkur+Zd03z4NhlehExKlbtRpjPms4XgC+zDahsd4skbDtTgULPTjZTywIK4Ik8jE N/M8BPkDZgItz5mNKPH6RmNcW4VbhShYENuAu2Vc8o9idEBrlGwWRESqAwajKt6eBx/1ef71 X-Proofpoint-GUID: 5gUJUmPqBidxOGjqBbC9W59TCjZbRABJ X-Authority-Analysis: v=2.4 cv=ar2yCTZV c=1 sm=1 tr=0 ts=68513ee3 cx=c_pps a=jAfG9cKiLM3L2FwKH/RKGg==: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-ORIG-GUID: FxA65OjYnEm27BhFa2iKz6bP0rFifR8e 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 impostorscore=0 clxscore=1015 bulkscore=0 adultscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:09:50 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218873 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=4f7b051f8ee3feff1b53b27a906f245afaa9cee1] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-4.patch | 117 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 118 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..f8674d62ae --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-4.patch @@ -0,0 +1,117 @@ +From 16b9af737c77b153fca4f36cbdbe94f7416c0b42 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 16 Jun 2025 23:38:40 -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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=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 cee1968756..47e834cade 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 Tue Jun 17 10:08:52 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: 65115 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 AFD49C7115B for ; Tue, 17 Jun 2025 10:09:50 +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.15280.1750154985065620793 for ; Tue, 17 Jun 2025 03:09:45 -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=8263d137de=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 55H6v8CE009026 for ; Tue, 17 Jun 2025 10:09:44 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 478xa1jy6k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:43 +0000 (GMT) Received: from m0250811.ppops.net (m0250811.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA3hFb028261 for ; Tue, 17 Jun 2025 10:09:43 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04on2056.outbound.protection.outlook.com [40.107.102.56]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 478xa1jy6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:43 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tAGtqsI3Y5ui9iMtNRbSns50w6ZVxnnuxsUrI+ZtkTgET08kCNsa3R5RbdkbS2fBDvS0XV8Yxe0t3eZENZnU1nAKCUAhIhugDdkt4Q/5yg5AxJchsPf/obSsPeL4FUk7lI20q4pDV33VGryUJUh4LrWCjI1vuU7hM3KHS1OpnEthgxOj0ygAR+QO597TE079bbU48nRNQaV7btosVc7bwS36zOIjoqaEA7Nl7fOiicCpnwqZfo07L3xtvVOgiBzx97tuKZqBd52jlZuvxKshGs5rrRzl+cbIazGDgkbhOfXan1Td6BkjCpvMQh5DxwaQVz6qMLU+R61OH+0XWMWe0g== 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=r0IrtYlYDhuT9PyDVaWe/m17L4Ov8b2H1wS7qIWgAGc=; b=fP2po33nqRlBRl6oDb2MFR0Seslo9RLYA3C5UiORTQvWrtzzahb3+YXcYfkVdcvYiXsXH1fIea3FX0eCmyNiVACE31PgceCivTwjwX8KwZ+IN+YnN0CmPb35z1yXtwF6R9MBUpPrLUcWFJkH60fjYTCucOIPDnf4IYHEIJqYVoegStp9GgsD3RC56xN6XbxzxSeVR+S19be3tFxswN52xY2zfN2V0wh3AQ379w+4IHbIfF1KS59+xWNFD6tqUMsff19UPoC1Zbv9oHEaJpFvBpGMsbSrgpE16WDF4poXqTYtSN+t/Jr0L/JAjovDHZO6eojF3LE7+9jtheWguwpQeg== 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 SJ5PPF12B0A4A9B.namprd11.prod.outlook.com (2603:10b6:a0f:fc02::811) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Tue, 17 Jun 2025 10:09:41 +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.027; Tue, 17 Jun 2025 10:09:41 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 5/8] glibc: nptl Use a single loop in pthread_cond_wait instaed of a nested loop Date: Tue, 17 Jun 2025 03:08:52 -0700 Message-ID: <20250617100855.2696492-6-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ5PPF12B0A4A9B:EE_ X-MS-Office365-Filtering-Correlation-Id: 3559c022-2a74-49d0-8416-08ddad871329 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|52116014|376014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: Kmk02cU55+KjfQkjIXfwKNKEJ8ptobdmDYi99QkUiWuyS1N9prWtr7plnz81NLmb+4XRP/v9y9QChXkTFiGRmWV0fMwmxoAuX//rAtutzRNUp53qQVbkECVC5hj3hp5pTIc4mK+J/PUSTzs8V9WN78jgKspkL2a6auT9PiKWoHD/oT96jPcjEr4jQCwg0aWnC9jjUduKKuEnvK4dVZfN6pDurzZydrfOCuU33/hCwkMompA+dEcYKfZE6vi9COxX95Xh5el+WU8+Fj6WbjQs7XmIZeo+n8MZQDoCn0S5AKTC+o+frGNBsX2WlCQ4kpG5S/pKs7VA5/SqXaaDM2Cbp0AevC7P8t4GBrJ2CRGv+AZBtea30iJXMPL0YRhKnMJU/4Silv5cDgznu8R9bFvVb46buxpJlpEs8UbzgMzIs1xURmlJev4tkMaxE2xjycdfIdBARsuGMcQu2l27BdtuwwbT9GI4CRdsdwvgrNuokKMCFJ8IpaGNdpMGti8O5frEYhDBCXJDDlj7BoESXwG3WptIF1xPtiBYUseYYbiGf0Fw8BmH6vBedLNgE1vJrCNJlctHO82E+K3phdMHF6aRZkEABDC0aRHNOqn78jsq0tu7LXYLjkwDcYWn/TuVa+HvO/LZc6C7SF74LNJdp4yC41AdQWLiXWnwn3dvhbMzkhpJthmcREV3Wp8s8cHkqnewp9qYw6jP8qVMkngz0enrzEHlNu2bofYRA2cc9mP9dDlKlkTGdGf7ulArpyQ8OQLdy0dBCzw8wjIcLEWCB8y36nirQJuLqYRDEJmDmDNU/bh3ZZL/squ6aRF84joznPZCAgiLTN7cLiXc33LVKkyAUX0uKSTytYgL51fyUSRUJ39etOblaBtntGBZTuGD1Yy4pDBr0SRo4jXzc4SSk6Oqdun9nrgr5RmISz57LC/YRdAds8mGWaauTu6OvbZs/RJyeVXUbO7c66h3dM1JZmtPgeuxXaxyDGnNDmDAPDvtKSIewpWo6Tfz2PruOlNPd+eToyjShT37zzvzK+GLhGiRKst/EFu2z5DUTUSrf4Uf+kjowSsMQvnThN6hxmtbqEVcygwe90GHWKwDWi0w77tluuFX5sgoXP7h0lpJpKutPErCTcEgEnbYVZTHZCcR0Ydk12f2QxhPMYZkAnRx0swOjT9bp5ZVUGPdZ3iNeXQp4dUB7FUrnb2LKRuU2vBrEzuykT4RyZyBKuI1AfnjA1mSfWB6s0p5cr4HOqtK1YUvHBsuyxE+eobY8I1iFPUAZ6E+iUx6Hg5RDv33SXjKUyq/Ue5vv+7aoPRLIptPsOxJ7AieInNl+kBuOui+nr1nl2A7D3OzuwxR88x+4EZb8HtUCEcEKJmbQDTvyWkcIg8W8clIafsmvMoUZvNpeWHCBbFm4Vtqll9mcfMnx3RvYAzxTZKI4vPw3LzQxXvb1fTgvYE= 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)(366016)(1800799024)(52116014)(376014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gdXb/4AWP3eRw6YrcQ+SJcAbtPKyCMzA1P3X/BxI5yBXZPu+pK1FNrIbm/jQ82GrHxf+w6RtKcdWJJhkSFX6KMyYlZfroHp1zTbWoOJ8VmUKD7uMapSdaWHit9N36oxadkXwfTz1oax3iGCu7kXkNJI80JYK7zn6sONZBeEabRAQK3UbbXmlWBuqZGQM/rAzf5/0nYFUmSEaPnuOVjF0Tf8m7f0XFU9JSfvB7EEJFlsjdncO+HXvwKkxva7HFva3k5wBRhsIkd910oE1CMY8nTQCMDZ+xPOFyk/tJXR4wf+dpCE+LO3FGmhoLbSORVkmf1ej54z4L7bkaoJjzhw9KSa9DdM7EAj3WfR2VWrI/ydDZ+SA4u5ZDpJU6gGOSnnCO9VVcVuPcbbWoE4j3HjWID0UWmFmydoAg6xIAAzwc1NrDhBWGPri8J/yCjMpX19zRye23roiOOYXRjzvv2iatcUBhOjhbnLgEhxuqUYvziqz2bG0Hopb7JsmrkSlRAZTxFWcciIgT2e83VOivDS5YLf5yysyiKv1VSR/za/oc7PHe3y4ShWs6SAzJ0BUc20WFqJ1gBy1DHq9T1VT2AdujoNGHfsbofAr1s1vI9qjRAroGCaHttDXuWLxLvC67xq17w6BSd9r4JGOV0JkLBY6VcCgl0W4xNzEvR53+P/2/rRUdHwb9O4+y5S4CGzBXeCwwFy7eoNMODR5urRJYsMiUrmYI6QP3RhTwFmFMb/+71Ts3C3RJUuFQeYzyji9N/ek/t20QUrKPEmBlwm/ImlJxvA6Uf0P2O16KJhxLv3CbtpdWb6ixr3OszPfuvPDRjjZbhp2vtYYQfpLFKY6vadOQ8TZOvCRYjKv2yZVrRnxpm38sjY9U82ufgivVGvdAPsi5K2b+fkTIznIAKkAejyGoKIdCVD89MfufiZQjeYJLkBDN9/vunDECirPNExt2UMgri2hMjlJM8s6R5dzLGcBZnIpnFqDuP5U2qpi6HIaRv8m6aYVhLyXKmp+5jMVR7rWM9g3Zyd/gox7alqIFUgr+riHwT0DPd4ZlwjdppQkPYDHnstbfUP/0P2qL1gQ3NEGcP90WPMt7+7Y+XcYFJQEMyE+pAC1AUjFZtxCbkWEWA9rGs7wgliPzuZIMy9n2yUzXQgIC/1n7wbMdG9TJRKl/91RQte5HJ7NNtTVyGnV0eYnD4OkRK9EC9j0uEX0r/L+MBJAklIvDhdF/dTQPEEx4PWL7Hp2Y0x5DZXjuj/dAVy+lTXTob17tDRcoI9xeWh4D7sZAq/Gh5WTHFFTYzjG1dUiKwGuZN1eIThZkG/ttZ4oH+8L95+Hm+t1z0PkPUIkO8Brg4DQhoJPbfHfvfUzUkT+wc8YTgWwB8pqCZDbnfzHagPhRvi6BZZ6s2T53G/efLuLIT8D+5fZf3Z9nZ2iy+xNfF8+ZHGYqnfPmZ7QWqziW0FeSkiBy6IsT5as5n/l6n3PZWelSEBDsmHqNuOw+4CyLcIdYbQ1Clf/b4vHKkuBTISKAgHjIkP4g9jhP0olN/AmMJW0SUlZCDe9Y6BMf8QOnyPaepIACN7RqJgCBjsMCJPLzQjhr9Q/6VJaMLdG7syzJlvpBgSB/k3JbxIjVQ== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3559c022-2a74-49d0-8416-08ddad871329 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:41.1215 (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: SH1AUWjTP+sLYO0Ym20ws0CkIjkPQQHXE5G6i4RYgz+YnX2qCOoa1PemL7vh3RnHPTOv/PgZ3EbICCnJBNr941E1EsplgzMnK4bfDdP+TAE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF12B0A4A9B X-Authority-Analysis: v=2.4 cv=PuiTbxM3 c=1 sm=1 tr=0 ts=68513ee8 cx=c_pps a=EMkpfQS4iubUv0iPKfbWZA==: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=fSV7xxviPA9HsJU1cEYA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-ORIG-GUID: VIITP9Y1TiP965mTRLas4EbOYHFhyH7e X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfXyo2r+883613f E7z6a2KBL0pHYBFist/iJ/Pz4jmLlVrXCJp1Fy3dmPhAX1MQTJztVAwkzFGFaHYlxc9TESsx5ug zG4EadOeScDBIXXIPNzj/KTOweRPVc8FlfqTTroFEaBLrZ6nQraj9ROVuWExAQV81Rhn/Ix4tkb 5iqpapogsmDrgxcKEWYQ7YQmyG6OLnEw5yvkL2f+xlr8Pttp9DvNRJ/1VBdJ7C35fiFaJakFDw4 VQjDV8UJS8eszBdNDU6yZEd+McUv83ShfNBPNf+qblTdp5nMI3xQJAoepEgwTCXHLTfCoLpcfgX qwYT2TKgRfu/fGQD7vuH7fToG6ARyid/PR/1wcgWHnMXlzJT1NvtM9NboDQTC11L8O4psduhU16 pYZMaFnYGPqQJ8isdbuE5IeRiCEOmMIWF371mhNt0P1QaSgRTwxbt2Zan52Qx/JyOVvlEtia X-Proofpoint-GUID: WgzmV45uBwxiLI-vAEa8yYyVZWsXDN09 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:09:50 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218874 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=929a4764ac90382616b6a21f099192b2475da674] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-5.patch | 105 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 106 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..16fe6f8460 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-5.patch @@ -0,0 +1,105 @@ +From d9ffb50dc55f77e584a5d0275eea758c7a6b04e3 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Mon, 16 Jun 2025 23:53:35 -0700 +Subject: [PATCH] nptl: 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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=929a4764ac90382616b6a21f099192b2475da674] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_wait.c | 41 +++++++++++++++++++--------------------- + 1 file changed, 19 insertions(+), 22 deletions(-) + +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index 47e834cade..5c86880105 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,8 +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 + that we synchronize with the dummy read-modify-write in +@@ -479,21 +485,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 Tue Jun 17 10:08:53 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: 65117 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 AFD10C7115A for ; Tue, 17 Jun 2025 10:09:50 +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.15147.1750154988658608193 for ; Tue, 17 Jun 2025 03:09:48 -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=8263d137de=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 55H6v8CF009026 for ; Tue, 17 Jun 2025 10:09:47 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 478xa1jy6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:47 +0000 (GMT) Received: from m0250811.ppops.net (m0250811.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA87ij003080 for ; Tue, 17 Jun 2025 10:09:47 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04on2060.outbound.protection.outlook.com [40.107.102.60]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 478xa1jy6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:46 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u2q1IWzBb0SEMQUTTT6BMtf0KUS5ci+hd05WJYaTh6/W8XWCJTQ/IuqfEdciQLRsfRG8qUghE7deoU+S8NRswrC6knTMQVSJBxlhqwNMB8YytAyBG9J1vuBpdHOGvFFeJErfoeyJrRF8uJCdOLe9nS/PbIT1gKTpIBJGhtQDvR7eDeMhwxmMYxAY3bmsSJ9fZBKki7m1y5rv4uxiW/r2c1oLV99ENeVxH47GGCo1l7YXN9gWKNYkxhwpzZf68ECFy9Qp63jtFZrmnffdOLs+olDQdN2RJ75UdvBfbT1d2O5IhrX6iX7MpO/y69uQMQQkAJhVyfFjvFVe65t+/4KIrA== 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=ZOM8zYDXVQrGsYCQPPzA7VWSwYyukA3d8CSsallujY4=; b=mW/NoGQclCSGF+zzC9NA9UeyAlVwJQ6Sqm+T0QTXNDFLsiCzIyUKsSVE0/CPHeeMlogpiA2IXACRqvJ7Np0NXgZygUMcIDHnOWcXyN7Qy+y2LUrbnnfZh859p5nOHCu6JoIbqEN5wBCplZqlVgOYqB2EOs+d8cYwK9XH1dyoyMP7Bx4JEU730M2UaBRVrSKrFkufVG8qVvDxHn9t9u5+0b12Tgt8DndfOr3WvTfW2GdLxEv07Na/mkGQ0WwS2f4IKlVcFEZKQjF6BU5VxKi6GPWJK4I6H6fm4mOSWACFsYbZDw7V2kDBqd8t4CD05LKbszOl7EYFSrN7KUdnutEHYw== 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 SJ5PPF12B0A4A9B.namprd11.prod.outlook.com (2603:10b6:a0f:fc02::811) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Tue, 17 Jun 2025 10:09:44 +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.027; Tue, 17 Jun 2025 10:09:44 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 6/8] glibc: nptl Fix indentation Date: Tue, 17 Jun 2025 03:08:53 -0700 Message-ID: <20250617100855.2696492-7-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ5PPF12B0A4A9B:EE_ X-MS-Office365-Filtering-Correlation-Id: 8d3c75fe-f149-4a6c-739a-08ddad871554 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|52116014|376014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: 6OBNsQpKhFPOq1dQoY16zVz0L+khUNgU3mlCiohDwf8vsjqaqjGtP81+KXWbaaFCbQpHZAarxTrIc16WxdBdjZm/qOV3ANu+X7x4Dm1U/vSEzoy7PGTkW+KwI4ByEtFENNOQLexSaqX/JyfDZoPrlV0yp11FqBHdCuH+bpbPV+vFL/KIFrjmECYNUpypJ0BHbkCR4XuPIHIQlywoor31XKEvY1kAbPf6MdyrglXU1JgW5FycsFqtVxerPSeKFIUJuG1dZWQfd9clkuCYHfI8iWFz0zO5J6UgDTMDB7qMMUZ/fbdsvBuFLhsNN+aZNo4mc8N6PLSjO9mhxYRPSwefVC4cCi+D+W4lNrsGL7WkCPot6ECkKdv99gTFO74JSTeOonZHXIH6bc/FgeVHAPivTR4HstNYjqsCR0sYUTWQorTazS8yq7x0lcH/3OKcEtb3lrOAOQ50V0smJH8mxhzJhDJs6Z2eA9wmFStgxB4lj6jo77owh5l7cpEMaCRogzbSCr6Yk+A1/LqDJJ4Im/0LkuxZ23JRRXKPRI9NWLq6FznfdX7DxebFksAga0JDgcTbmSm0gONOok8Z/wPIvQhb+yDZ1qEnd0nWdcyL2hgve2hL2VF8w6P/v6ibfG7zVH3OWqvsmA+o8pue4AP+eKx2fsKzAU3YDKIA0MBMEBiIkJ6Jo7j7c+vKMUJysvlvEPZ4YHOtMfGZjlhLJJ6Xji4xo/RKvOX9DX3KBBJcnH9Tv42YfVSj/SNHznJUfioEObeoH6erRkZOA80CFaam+EJUVofqGLiVvOq7w8TtRxGCJfEe+WHfwzr6C1e3h0q8bwy4SSX3/mnu6rZvvDb+MJHUP5pyvWhWSFs5Q/Lj9OeQE1vmFb6kdP0kKbRQ/Jk3F2MO5A7AokCj5/x/alRI5sW/0i2QWrboYN0c8p9qxrp5z6iQlsokbqU/VaQ5fzb47N0+gDLDLWdwtfayMD48uir9fqP+TfVJEdQa0NMijA4pO2Ovze4Z4e2OBxQ5WH0kRhJr922HdMfbQSwtjvsYJefBaxmzlsufAa++iiQmeAxAyfzs7Ce4CSRYvRNfTElJFjwuSwVaEEsB8utlpA+wbdYeuwfcDm+g8HvGRAYIufHBJUf2J0V6EW2sW7Xqfd/db+d6ySj28uXkeWlME1cic24JmyiktoixVtIKg3MDqYFxdIempY9IBajCbRLg7OSrbVfoEn6vNF0a/3u1yop1+P++NP0i/uqC2EQZreL5JraM8WyDGCt3GMUpZ317SqsDLEe2ttbCnvDC7sKZDfIx1gi9aE6M72OesKzMjXHcLNh44BuObkF2OouT3CXuPvIStgDhK/jG/MZDSrmiT9443JXP54OaV57KQrnOg7nf2ftl8ovjIGGHDvX5s+esmL3ByDVvoTAcgv54bwj+6rCispMskeCa7p6ZHxpLbtzu6gX8aXA= 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)(366016)(1800799024)(52116014)(376014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: oYYnyZ7UrnZ3tT8Dnb9GfErb6p13/WJzNYdg9Ji361SSojrCs4ODKIadfoxG+DVTZECitmOIci5puZ1nfHkF2gvz06dqywB+7NUmq98QCUoUuVKfFChyPBJKXnHXmTvoYGcKRsutsgaYaX30RlTqaob2t27rGJG+FFIaU7QBci/VdfrZ9/id7QXOjIiGFOH3CpoUOS6NpD+1MY8CWYCox3gZR/h872y7jLPo303zL6TiR7fDj2N6NnlXafwr+FKWP6SnjPnPENSv1Sz3yBJTja0YG4J/6QlTbocqwjX5nNipW9ybc+10QptaQ3lCnxAzA5FnIqyOl3C3MkH3cAaGQ7aj3znm6owMyTK/1gco+bXy2VmksUytoEnnfQElCOYaTMH7qNBvaSAZR2G3qA/4DrQp3ZkmInaD+AdaoVkOZfqO/DnllG6H/kHbNornW+bQD8fjau7yfr7gm7hRnVqVCP9Xz3vJivHlu2yzCRh7WdEVqARp9CINEAAvL3VKZu7SAmFIWTEJyemO08I9Leih3kqhktpzqE3FWFuTYyGJmvTjN31bhXuQatsOolikyOe2XKHrqps2cJc+6cTt3LBcF4ZQ6/9EvGn4IVwQJjbnsqDCrI30X2zGu6C47naaV8SfeUKRy+i1w+hcXK2lQ/f+zsPTmVooh4u47SNrhq2iaA0c/sRVxKFxnrhtLNJWpac/VIQCAmBu4xOSjbMhB6DYXphTvrkCmjSLuI0GHHlSxhvvMsFhykS0rTHjQ+jS+rdmwPhnoTnlhFb5poH+EUpQn9bekh8qsgwTNyoecYIqgle0+LXWJY6oPB8DrgLZ1IxDi0oia2DCWmQOwnvkNUkphs+kYKqxoLLmYyloDXGqI34otlbZPFabl2MNwiHh6UZnYCZMTVLnrL3F08kXri38VDCF4o+8tF3lbesAAd8NPJ+IRoHiDxGQPtJCfdc1zNgjh90yrSKOIk4yO82+YcDFrKYQ1l2jZRbnzmd/d3qO9Q7kgkk7sQLImHItxosf1KExnPBOJri7jKtEaNw53sY0onUeKQuGgz2vU9Fwg1m0T4zq/+yMK/jsUTylPU8d17+zpRLAewX/cZrspBAAb8ddRmnD3I/zJPCpIU1bM9P4lMxbCuystWxdrgVM+t0+ZF3+IflRg/crmZi/Re3kBeWMX69xjavzDYUYUJAer1O2mk/2b2QduWbhe5rQTnCSfsWGbMVCoXvzsgSfZmKtHMfhv6osVXXP67DObssuV5xeIffav0nATthJtJ7j1C3zUhMWC/ufK7hvkE+3P3Fe5YezwfaVM4kctEbdhGPNrBGgDe1IM/ApEylzJcnVkCz9MNeONd7/N070r8b1ye3P8KmKbTfR9bcYtAv2gE2UUguCP3T2EzYuHV1pUzxTjexrXI0yYBRvPwCxKMG0C9jSgmAXRNKoueQHR1T8W53FOZirkgRXANdEiI80jMxJ6zkk9qO68pbgWnDaTeVjAzyk6vEhCcBa6LbhKzOi4jwU+x7nWub48sKPX2PivLv0p8FmMaG15qTRpEe2gwQJ50j808iKUzmShSrySqgp8ZyU2fMuFOPw4UhegN9DMZtAnwCd8+Dr9JC2VPY08GEEKekXraBMgQ== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d3c75fe-f149-4a6c-739a-08ddad871554 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:44.8178 (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: 1Q3Eyxom85kcG/tDM098lrXQOnkiFTKD2rBJjnX7LaE/hod/lhoOxt4Kcw+h36204TCJT3AUuPcKpXkRoPVDUN9B61BaXJtO7NHczFLdxGE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF12B0A4A9B X-Authority-Analysis: v=2.4 cv=PuiTbxM3 c=1 sm=1 tr=0 ts=68513eeb cx=c_pps a=up6PulAVXqy3i+yUvDkarA==: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-ORIG-GUID: zTCLGhtcXytGmtVkYJIpk_YWBViVFoSx X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfX2a7J3q/Ie0Ct wG0wFCWMwhKnA0Lnr0jAtUXXD2+mMVa8BqnsLTue2SMyoOUJ6824k3ilnhfrmuL0mdEAxA1he2B ElTeuYyVhKe38ewUg/rHDp/2wQ8Tx3q/tIJeqoDDRtxWOrC6rIBvLeBvFNmeiNmz0UQgC8izTc+ xfjpqc7BxlmQh9EIXemjCEANWbd6zLo4qJwuOTdcjylBNgADMIr+1nKXgKF33CIShlj3OMHA+VY dw0iYHP239hqMwugm2s+R7oSQq/GAUI/do0O/0IU6mFfd56sptlqtEf0AfhyJg7UhknK5a3Ja60 1J2OoNa6/HY9uyc/1czR61/TNt+QGtRV/JI8t4VbacSaKLVppvUOWLaAWAz5asZWvK7IYqdS+CF 2tjTkSOmtGIrc7xsp436hVqzTcht/ay7T0uI1E6AjmNnwsENp5jsZODToLgH47aOAcUb7po8 X-Proofpoint-GUID: GOp777M-1ZNfvRkO7L-ts4jF0vcyd67B 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:09:50 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218875 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=ee6c14ed59d480720721aaacc5fb03213dc153da] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-6.patch | 169 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 170 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..cf87e21ddd --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-6.patch @@ -0,0 +1,169 @@ +From a2faee6d0dac6e5232255da9afda4d9ed6cfb6e5 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Tue, 17 Jun 2025 01:37:12 -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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=ee6c14ed59d480720721aaacc5fb03213dc153da] + +Signed-off-by: Sunil Dora +--- + nptl/pthread_cond_wait.c | 132 ++++++++++++++++----------------------- + 1 file changed, 54 insertions(+), 78 deletions(-) + +diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c +index 5c86880105..104ebd48ca 100644 +--- a/nptl/pthread_cond_wait.c ++++ b/nptl/pthread_cond_wait.c +@@ -410,87 +410,63 @@ __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; +- } +- else +- __condvar_dec_grefs (cond, g, private); +- ++ else ++ 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 +-- +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 Tue Jun 17 10:08:54 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: 65118 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 ADA8BC71157 for ; Tue, 17 Jun 2025 10:10:00 +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.15148.1750154992854708930 for ; Tue, 17 Jun 2025 03:09:53 -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=8263d137de=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 55H6v8CI009026 for ; Tue, 17 Jun 2025 10:09:52 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 478xa1jy77-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 10:09:51 +0000 (GMT) Received: from m0250811.ppops.net (m0250811.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA3hFd028261 for ; Tue, 17 Jun 2025 10:09:51 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04on2064.outbound.protection.outlook.com [40.107.102.64]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 478xa1jy73-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 10:09:51 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nteP+tCfyF1b/UXGKkdtlwDeqtevyBTgimcrY6Zrgr7N05HA53FghR3arvoiOBNjxg9LtjNwA4gvpxhhasCVXprkC3xllDBJZR1fI2Cfl6e1XiqKSrFDYFio30sDdhIZdJPP0Y0kRwvZNmCwi9+qJHIC8cZOXdQr4jXVlwaR+mcNolk8zwSprwBJI9lhdE4JKZqW48SbDEdcej0BRe9om9NEaIxBlvNpfcIKd0XPj5Fk3DyIj7Od68oL2Gx/gMgmW8MzWX9kAKll6fpZ0n6DVOMswT9h4sWEhYHJ1b3kXfTvHor05Su8nRLgtT0duRAfVeJIgY23D3Q1KsH1v5cbKA== 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=Qbb7Qte1jn92QW5PknwpML7H64n2hYUMGDNfeEkBriE=; b=WMAwIyZL5s2Nh+hemUZP70uQdgbKwwJ2vp2v45jIhbZRI6IfqyxZAPPEr0c3h98H6wxHrczsCoCe7WqcKKOw7EXd25QgUBEHOmYXH9OLTVsrj7EoXAW+wVNr0lX/kmVa3U24TDdvSk5sdGArNrnNOpepHRzMh2IDqd+7gt8QtWi/UYa9dFIlcRZPfCa2ifXZu9DArvEIakygQn0BVT52X6SSFe+c3sjKlsr807RHafvC95JohlYw+UmzkzELal0SSnn0VMkl1T/zHfyYgn/pmwc8WQr9mJH5FyudQcExTsSwYBLrN+sOXEm0RXiUJVd0ehkd6/353k0ZwXXGHpBOQw== 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 SJ5PPF12B0A4A9B.namprd11.prod.outlook.com (2603:10b6:a0f:fc02::811) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Tue, 17 Jun 2025 10:09:49 +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.027; Tue, 17 Jun 2025 10:09:49 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 7/8] glibc: nptl rename __condvar_quiesce_and_switch_g1 Date: Tue, 17 Jun 2025 03:08:54 -0700 Message-ID: <20250617100855.2696492-8-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ5PPF12B0A4A9B:EE_ X-MS-Office365-Filtering-Correlation-Id: ce97cb5f-ea07-406a-c18b-08ddad8717d6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|52116014|376014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: NPVQ8WP53eCRZRz0vq7fNfYR6dvksIWNtYaKyll484lBCCJctTAC5B2fYdu1mzA4Pbnv4WPCso35EwfSkTB5bWpw97uqt3G+Cvglw1OgPrC97jiJObXOQ9y1NcGChWNkxZxTAILe9g+Bq5WXYTfnWp/EfREVMplOAd2XkxaCvV1B4KIUM6jwYh/7pb6syaEVcMRkRlDMA/SjTOOEN0dg2Maj3vgGD/jR57YQ2tq/iJrSwA3hdT/Mb5sXXutmCaitCV4lSQ2PUXiLmvoemgtOaP0F5IBFCNOqh26dMb78kQli6cS0qiILy5rNC2sdfWPm1rS+ca6Pu6Yo/hrjzjo2yU/Ig3BL3Qmfb6neMw/6F0WgRBMDF3H5l4sZDlqdEq6hEZySWj7UO8qoX3qClVWupdc9wrc65YPRLG0mw4QPlgHD/tUNidYXkVmAO+ZELKxz2Ghpj3Taw5QKqjo2oWO8wE6mebKKie5oXBR2mTBRrgskT+/4vaoCKlidWOZ9C54MAAzw9fj+NVGRhyvbwT2d07WlILexIkN7Jsnu4cQ5M39NtPbdaEJwhST1qNWSJ7MP5qGG1JiaKAvgXNNPPQrtz57jwlYwrMztuCU0MvwkgqhjXVhgQl4mLM9zdqpx0p7WJsqB5xjEmA2/VmYEMzXuvRjNc07bB8iLeX9l7IAYiILOJWOKRz/gm28v0pZM5LXF5w1vzhC1cOBiBZKWIhfuIjv6Zb6B58h+0B3Jr+2e8JjdyXivPIuSBAHyXmPS2GXXKENE6lKuP7YrVDrXIUxslhn7syXW0voE0Km9sBuqPNAs1pLqxe+zGb5LtdYLdFN1BjdcgTgp6ZnvYVhwcahSPvBj7xdLSBEMHBO3XzS82/IS+eBIsswpt52WDh/mAkL4kWcOpMO9emvnkhl81fPJRxic/vJOlEkWGa5C9SRf5olDUh8itt6wtYTSr3mrtIecB9qcqR4Hgk4OiqlXM6h9bIjx/ku3b3ivzCdWjJjR0ZLf0g7F00vXTPOiUHEuWqsvSVC9o99kd9SAvCKxgxUOc1syf205J0weQdoCQyrAP5f2SPXFTjksl5+2dmuOmyiDRSXXX1vROhSwVqUh+C0sbAM/IH8LIHSujSXqOK7H5uaTN3fAhRTLl/qF66hGp4KYMhgbe736XUBHjKXxZFOC1CiXw9BAj3TpUqOocSeVVC6KAJ8QekTuDcdN4lBRXsCBzdLjV99HSXI01CV8ctRAO3T1vjqJ0Agwv9SM8GS4TxIMCvFjwlwaEOPAjXgF2jav1Rx2PBQ3OQXI4JeMWdw7CQISzF1iCgawI8cKYt/MXPsC0BOaO8jKOkbhLGQ0nkPkSPfUHrqTMIADjRN8DOwrGrTHl1/5y5XDkvecXy9JK0ApnEoDtivVp2e9sXZYs0xtzlEihmfzaFfHdrK1o3nUHmiZlXEbWAONfP1wMYFfo6n5HohXLkm5DEmd7NZcmSo8 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)(366016)(1800799024)(52116014)(376014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: n0UNeh+LPzldozsReGqE+Io+Y/9RchyS5gpfPdmc6N7tOUkHP4O93ZrzUMSLdHabZzqNpQtpDTcFyJw3JL4hHP+DcHuTh2d3pB9BGtu3AJUoWSFDK9En5x+XOL31PCsjdp927K/kAIIp6s8pkrPiZqbiBFLZuMI3F9FwimyVlBgz/6XJ80YQAt5XYKyLPa/ri3h9OTY0IqiCv8El6GeaLse8Nury7PnHQWztRHcweS5EY+RFnavSaCBfKzps/zPzN7r8fb7qPwdu+Z6EAEK6BvpUPqhekk5RTSPYU9FUmG2+KH3SRDyqt7oa18hTUVgjCwayDBKNPJYJ84zQLRokMMXuxFgCoivGDRtl0V6apruTE9vr+6qiHhlPkikAQ+FSm/8bLIEycZUa9H0EQ10jpr6wTzpQqWoSBF3polSG//XzlzLOouHaSK4mJXqAMkT4ZTzScAU35dfmYb+kvrWQpbIeCP3ynXc3lqTrleffTPRHDj00h33BzKPLPQIFN3D/0h6ymC47WiRjJyLkwUcK6UApP2xbU1oFtEpWDTTHQmbAXgf2EIi2kzCqT5bucJhBm14xIxPrzZPVrGj14OhomQJTRsCZW87yKVF9CzoAbbqdB3vtm4ONCjHbwph6MMYCHt/iOMsMamKsYH4cKdZgIsrzLbWfWZcD6AbMjxIG8Pb3onLKVoXxoO+FsNRrE5xbwS8/IIIwXS+5XuDvTCvjb6eoCLr0s6SaDE11bfRWDdAIujaJSjftUZpaKzrRHr8rl6GMalLgFB/O8ChRln+IOrxpG1w13LWiyclIgGiOttQlb/sT6p9tWmwTiG70WU73rPjdBtWk6dbigHMDo+/3opeYMrFiPboBzSWqDhizU87X4omqeZG7jMyQGT8pRn4vvpZc/2FReQvew/o+3AzAmqFHSUMB71eq3vem2q+NpZhBMHgRrWdTWEhQ4TG4tTksSIBN+2MfSIP4tW06JGdJFI+MQZpV29tNt/bYNr4hWrUCpXufR3/8JRwFT8r1f5gez00A3Vxs+lS+w0cDh6kGBBVCNI5ewVPjlTTZfAgX2FX8mpY50C8VkTubUwvT9Hv61FqRnH7rswLumirPgSGDVfFih6Sd2p5GwdVeRN1RAAvYWDgmy8Gsm8kPXJlHYU5bx/CIm6u2x4ehir/c7E0FX3Z6ilIAILbtmqYc2vKmNTMGumDgiCMI78AV3hQtXnCZ1nwykC/2wf+oeKOzhPcKbn3DKvSEfvkO5SyuWsgXiMQzCEP5SzL6Pt1pSrzsbG/UZjNnxse0MTV4wB6brAcuB+i3mJz8OSHHcJlT7AL+5mqL97hoPhjF6HqCIr1EzhAPM6VX29cFdMFmTZrvJa8r1hxbEDCoboh8sNOduKmatkG0xsvuonED6v0/HmULrt2RC9CHsxLEOfLUkt6bVpCMMXG0wb6DeAjpNJrrgOhx5p+M58RjgKah7JoaJvUcuFWj5M2jaM+Iuk3E0AOZz6HEBWNSXpSvI3KaJIkQY2Ux+tWrwqzffdmO8OgOswi7RHk56tBSQthc4ySaGh0fQDAN9BpuTbyISCHFk0IYVz3kAzNjYRldTEjs+sXq016qipqJW8WW7pPu5ABFkml6NXc1ew== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce97cb5f-ea07-406a-c18b-08ddad8717d6 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:48.9847 (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: avnDYnL/6N4zQFKAoSkR07cVKhHyPQhar8QR6bzUNRIqpEkHAioEoMgEwPSIiPlHPdqG4TXZ9F3bFfGDdQexh9PxINfPPd2cmapT91awc70= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF12B0A4A9B X-Authority-Analysis: v=2.4 cv=PuiTbxM3 c=1 sm=1 tr=0 ts=68513eef cx=c_pps a=hgGIz9PNuEDlV8tZGFw49A==: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=uyKIICsDoPcSdIl6ehEA:9 a=ul9cdbp4aOFLsgKbc677:22 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-ORIG-GUID: Al1OEtXoiTmshdCRWqu1URfTxamWQjid X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfX0JQ7B2Uk5XLM uvEJAJzGoN8GNi/Qt60Gtamc/13XkCYd/2oz90AN8/mENOgl5kM/PBiuPkvpPsCmOrdnChVoVXy b54Czl8+RCam5i7pvCoeRPdN41Ra9xDoXywtzHcx2oJASnlHta2e4yNTyIs95ZsxJUkwPmc1BX1 yCeSg+O0PBTdo/3cXWTdChLMa0dMuVkRDWNefxebYqKjQ/2U1W1uTK7K5+Vud6QZsjXoRz7T4OQ FolGrGsj586n1c33VGkTqNh6sf4cF91jkiIGbr5I0QFRUHYJ6Ee0Ji9/A8bZ2oB+sH4k98MQzrK 3RVHIVSqzCGGLcI4V7pxIDCMl89v8GaJvBU/hlSCHQ0GOBZosSebU0Fuvv9Uwyty1Y4KExr5lDl oYGxfOrRkOca++HAFD9PXesjkDuWx8YSoxZ49oBcbe8iQeZcJN3U9BCs1iDyM8nGDQiEdsvT X-Proofpoint-GUID: XU_1GFrfI2JFf4zouhSNJwXsJWBVBqgq 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:10:00 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218876 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=4b79e27a5073c02f6bff9aa8f4791230a0ab1867] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-7.patch | 160 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 161 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..a9e9cc7c48 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-7.patch @@ -0,0 +1,160 @@ +From 2a601ac9041e2ca645acad2c174b1c545cfceafe Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Tue, 17 Jun 2025 01:53:25 -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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=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 5ae141ac81..a07435589a 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 f976a533a1..3baac4dabc 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 14800ba00b..a9bc10dcca 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 104ebd48ca..bb46f3605d 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 Tue Jun 17 10:08:55 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: 65119 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 B4C7DC71136 for ; Tue, 17 Jun 2025 10:10:00 +0000 (UTC) Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by mx.groups.io with SMTP id smtpd.web11.15289.1750154995502866483 for ; Tue, 17 Jun 2025 03:09:55 -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=8263d137de=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 55H3uTe7001145 for ; Tue, 17 Jun 2025 03:09:55 -0700 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4794c3tsut-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 17 Jun 2025 03:09:54 -0700 (PDT) Received: from m0250810.ppops.net (m0250810.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55HA9sGU005946 for ; Tue, 17 Jun 2025 03:09:54 -0700 Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04on2040.outbound.protection.outlook.com [40.107.102.40]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4794c3tsur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jun 2025 03:09:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ExVmV3SJUm/1mTXt4UENo4Y90y0hKyxxOMqC97voZYhzBhuSTOcjPgIvpZc5KNgP9g/VWecx7WjvDGU2ENm3tziuLr3DthiDaCSocx1gEsfJEys9Zjkfz9a0Y0wW4V5bNgx8JagJyO2KyRTRjFyutJZXZ5g6Uo7eg1vzpGs5EqrOZCnU38/7F7tc61uFzQCaJduYbiRUg3hiVfPFYLs4V721aTCtcenoSQb082RfvQRD3eOVEFiMD4qjyMks1jRlYliPpoWLxXHZF82+yAU2t/mi6HaUcXsG8FLMeGDVxB65SkH+9NhY8V6r1f//vdT6I606lNd3hPBK7mlQ27VSng== 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=2gvze7Q2bbAD4TIhveUAG7zGSfrgOeFu91U1uQ6WUYo=; b=beC4TtCljQUHAEb52oCmdTfrb/E1vJbd1afl7USOjwOOQY3evxQu9h2eDk/lu6DWQu4VJzfsPxDJp4JgG6NYSQrcMl5FijSqYXq7DDA3ud06YJUlopL3Cg5MVlMVWJAHefQiqqETnurdNHxG0x6qiuoZH7yfPHWGjT/KA//hrjhdCfrWW7SYcIyegectqiwCJgxg+zO+75bGVqJvtawh/HueQloWALhWL+coDstL+To6koSvSF0TbI074Gbe1noFt9e5sxVhMZ0UwgQw2syhc36hVAfWYJF9dH9HGF/zTXNUDX2wbLwnbuj68v4bys8JwltPoTv/3n8T3SaX8IO1+Q== 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 SJ5PPF12B0A4A9B.namprd11.prod.outlook.com (2603:10b6:a0f:fc02::811) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Tue, 17 Jun 2025 10:09:52 +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.027; Tue, 17 Jun 2025 10:09:52 +0000 From: sunilkumar.dora@windriver.com To: openembedded-core@lists.openembedded.org Cc: Randy.MacLeod@windriver.com, Sundeep.Kokkonda@windriver.com, skandigraun@gmail.com, steve@sakoman.com Subject: [kirkstone][PATCH V3 8/8] glibc: nptl Use all of g1_start and g_signals Date: Tue, 17 Jun 2025 03:08:55 -0700 Message-ID: <20250617100855.2696492-9-sunilkumar.dora@windriver.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> References: <20250617100855.2696492-1-sunilkumar.dora@windriver.com> X-ClientProxiedBy: BY3PR10CA0030.namprd10.prod.outlook.com (2603:10b6:a03:255::35) To DS0PR11MB7901.namprd11.prod.outlook.com (2603:10b6:8:f4::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7901:EE_|SJ5PPF12B0A4A9B:EE_ X-MS-Office365-Filtering-Correlation-Id: 3a0ecc57-7c1a-479e-9ac1-08ddad8719d5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|52116014|376014|38350700014|13003099007; X-Microsoft-Antispam-Message-Info: 6kNk6jZYGhh+3/oOzlte66PXXstF2rwoNQPq9acRTnvYgf8EPMUtYotn5wq2HgK8/aqpslgEb/HToqazvJUiXbpX8JVdwaP5UQ22QfrG3FOHI71DfQiYfF6ALnT/yZ8gziqoeaU2152HTxusbTTwFjRk97kMWdab5kAEHzvz6Fi8Ag3pdIbetFMks3dsMA5VISABXsPJRSaZgs1QPEI5U9siPCDvbMGKnnDCzP6fLPGw0HB94NUCvrUPQhTKS8e48exV/t3q/CafgZTic5e5qs4Pi0ZN+5PIINyzr2FVrBjEB/FBlBp7GO/qUBmM1HQKAuXwQ0ZNmXFvBDfic39N+YrJaXUYAQXJd1G2aoHPy+KOkzd7cneLEsvbxbshlCH40HDNSPNnh/EBynsbuLYSCSkJrtqWLOm/UDH0WA49tQ4vPw0Y4UAPYDGFcnyKKJgjoI/Imuo4S9zm4pdM+Z5+1uGJwxGkyXBFpmZXtgq+yR8pXGFVcYvhhLRtd2wiz2CJyVIv4OFESnnIjfdLqoiql2IcyE4HNdHLcJRRfKHQLldyxf5D2XnjXZxMraSbugBTAjMHpsljrJ8C/PWNEuSpKVfkrmmY7CDmgz5ZyrX7Omunq72soAbo9mHyqGFXLtSp0hqLFxikfr51trRzMIHI0W9f5kIie0xODL7e7BqjQOcRzg4vun2xJDUmE+/3y5g81V83Jntf1QxsXFaeNo9/05FXD9fyg4dXcF79hkQjWrWLoEvga4RoY0HLVd9qhvW1udS030DRRXjPuxSofmm1mYPHgsIRrFKujoLN0x57C57I7CMmPvWCsnl52YV+5x5omx0jStWUNVA9TsvguqqISx1SeKs71EouOXndQ2fH7G3bG9NzQZjJqn75QTPkm/9aUKha6pDVH3TYebRdt4tSDkGQt69+y/bOC/X7UJKF4yCX5rdCY62XD3ooXeHL0yjQB+psj8AoJXzK086ev1HeH9m1QdOKQWMjRpA0ihjBcwm8vWpmKBTb7D3J0Nn4yB7o+Y//j9VYiwZP6NGKLGNJckJqNH7CXa+45UUQtuivWq36Gcq3F8n/ypaIrF0VFQJ6HU6C3MUaj9jHMzS+RQRD53k+vYxFPxrFjHL4fuw78YyV/gBH/D6yaFRsfoRq9RMh3iD6D0HOKj1K5Sv+zu/zyS8V+1oJ+b/YV+1WNz77LR9vR8sD23uPLl/w7GEDKmE4YNuXEmprmF+fn1V2i2arxdvN6+B1IssrO0Xt/Yb3mkMLFZiGMFn+qdUjFfdgrFPWBMm2bNOFqBmO8dpnYBVcjmenTYyBsxq1ljxtnV5dCR1bKMl+cCPhOeekiRUieFkunO3TK6/AHDe95bJOIXobSvpA/eCz95dTAX4XHhaRm0CYc1f7j1qX/BPDS3wPXmMzVfbPvXGfnL9PDooL3pyv7nPBqwKptGZTdjzi71HDAm8nIU0OxWaSNWOzpsPibopk 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)(366016)(1800799024)(52116014)(376014)(38350700014)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: YfuBpClO/Cr8FpVRIAJMM07bWSI8/HSii4DnRgLURBj5gLr1Be8JO9XSPGGzzI2OJ2i9N2X4mztpMBNZizMtem78AzF4fu+VDejOz8b3sspb4da1ND6fjnFUO0Hx73pBge6bIFEdjXDZqQqum8Bm+l2K/Z73gdKtzNUwaoNsBxcIjumjcSUGeLJRZaOCINza6hUS+NwNFWExaqzsLQYpUB+muwcUQEwwGXdLF4dbys+O9kMz83KuxEKjQjPKKHyZxNGVEbT1N4OERFQl8tbvB6g0SA6UCuDPYq43IGiHIaRfrkcZgY4vgMFP4hKUloOYeYRoL8q5YR8qIWExqrr/GeCxhV3x6lqrLKMHBMszOYLfdiVpl/3+fg/M1XtHZf1wCkfmnb3r586xQJlTyL063qVbRhIXPazi14XloLw23VAR8lqse10RQuR0Fl2sF5/Zqqxc6dhcaNmV7oUjm2DVFQr1PBRvswToS9kG6TAVz7KQkN02mSRW1prwucJ4ztZcbT3gW3vZHrDivCYqz+ygSnMpHDByljQto874yh+2lwg1Sf/awoEc/35aLeqpJktz3LMEAzSfkBKJQolZ/bn6zI62oou51FzxU1rYr2bDKhMn/WSWsOo9WlUtYssD7PMfcU6Ei9Rq5Yd7+rPacdcKkG9D/9Qw5aMZX3wzCOVMwHKtAqKNjd5XF1KqMtZhJrOrXvlzXFNh5dtgtuQLvupAp9+1qCIfyaLqoi4LSefpK/6rNGnrMV0T0yHBHczDCKdbJSIv902mcdumVD9rqPcHpLwz7q3SBFEBsOv24Q81odxk9AaBWFYsQ+1p210mWkOonUT6j5eeHuql59/LJkMqBD9m0J2qHkwSok/Ri6PHwyRJVPNDMXUA3avR/OVBrNjHw4BsxY0+Bg/8Nm7/7ILWDNoBvgaZCz96eoJs1sKa3DJPGPLw/ECnvBbEnQfUljoWc/ODBk3jOqk5YGbH7ZpRL0oxVTjBq6WfV94++Rpo/xGSRdWDVE/O7WmAS/OBlmIB+0tJMDN1zb4CQGL56A2+EGaW0sIRMkNhDuf+8IcffCJKj93nbPnOiCyaLlg8fw3wmfWilSURjbM8nWUTLIrH7F+HvyZe1UC2Fd7T2/QsgSFXGDTQ/cdbxtkoWxqfGIKE8RuoCyTsi98qzaSry29vL5U6J8tG85Rs+lLwhW+dyO3VHgVYgdcWa81yZohC7KvwDq2VDIbRJn8YzEi938l4sgqgj8cNOysnVCdB5Ar4yUDSkZfxzGk5sLqLDOdUe/xFxUSL0NNrg7ctDjYyjevWZB3gIyzaS9XMrF+P/kLZlkesYlyZT4lsiNLI+ZSSv2maf4YoYPDa2hGqEqSoZ6lXnkU1NJdGk+DvGi1XmOQtsAJDSdgh14AmWGic0UHife4n5Gt3d9k97nsBF4Z7PdpE9RHa5LCAg92HvSw0NErfJf1RGTWlATHbA4K0YE4oMfgM12197CrrXR1a3UJ1CAFjV2GT/JpSVKfZm5cEMGSF2jknCMdHJ9yxrFUGOxLV6qAlDKKX7PpVUoCgVtutnU7QN1Bu6v/FwIxFJIzw6rRYF6IjbVzhzpX1/4J1Irt1MdSBpSHIZSSWSUfdy9QSQGP8JQ== X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a0ecc57-7c1a-479e-9ac1-08ddad8719d5 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7901.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:09:52.3511 (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: Axbr3n+9bgbe2UFDgEXbgtDJGVSR74b1Jwv8cO7zWUkvQx9VoTOupCvjgfxVR0aA//PMDGAinKppkzQTmoOLufw3bXxmqMprvkW25o7rK08= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF12B0A4A9B X-Proofpoint-ORIG-GUID: LLh4AKEhk7m1wC5v_3geCWwcKzh3AFdq X-Authority-Analysis: v=2.4 cv=b9Gy4sGx c=1 sm=1 tr=0 ts=68513ef2 cx=c_pps a=YRACufkBk+Nn0Aes1d57Eg==: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-GUID: R1EwJX0U_Us07N3ZvWq54RvhtHauox6W X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjE3MDA4MiBTYWx0ZWRfX0ffwJ2nySGEb Q3oMFRxfYbSTnMKVUoCZrydI9jfnpykcd+nyjbnmgPFoHlTvdsNY4FCy0lGpy4abvBLzmGIXTFj XOUpW0LYVII/e/NrPjhlw9e6mrBehROVspNmybnsaTt3nP6Doh/iky1jvnoTmMERMP7ijkJKJLy /BtV8MLqbE4HddlGygk9+Ci0dNMdaPyuxlNfYXs0l0sbewf0rWpFuHOPFxMlB/wtlOIUjUOlaU9 0+tcQKETWh5DS2ik/Co5SZToAEfI5azGx/ZZJL8ouRdjqtgJptU0Ma+1gm3Lqf4O0UFoJjO0wFc qujTQcbgQYFi4dacoIXFuGblhEwoKUimsgi08VGIzbhcwlxibrn3umwO+LEdpsStkXzQj2fciqf PrC4MKShtwFHR08bndCZM4kkuZOndIq9H16J8M2jAU2vwLmNiwYZUX6teL9gLeVXS+vcDCX4 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-17_04,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1015 impostorscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 adultscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.21.0-2505280000 definitions=main-2506170082 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 ; Tue, 17 Jun 2025 10:10:00 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/218877 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 [https://sourceware.org/git/?p=glibc.git;a=commit;h=91bb902f58264a2fd50fbce8f39a9a290dd23706] Signed-off-by: Sunil Dora --- .../glibc/glibc/0026-PR25847-8.patch | 192 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.35.bb | 1 + 2 files changed, 193 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..8ea0c784ef --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0026-PR25847-8.patch @@ -0,0 +1,192 @@ +From fc074de88796eb2036fbe9bade638e00adfd5cb2 Mon Sep 17 00:00:00 2001 +From: Malte Skarupke +Date: Tue, 17 Jun 2025 02:08:36 -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 Glibc master branch: +Bug : https://sourceware.org/bugzilla/show_bug.cgi?id=25847 + +Upstream-Status: Backport +[https://sourceware.org/git/?p=glibc.git;a=commit;h=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 a07435589a..ef0943cdc5 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 3baac4dabc..e48f914321 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 a9bc10dcca..07427369aa 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 bb46f3605d..430cbe8a35 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 \