From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F24B7A04AC; Mon, 31 Aug 2020 20:45:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4CF8E1C05C; Mon, 31 Aug 2020 20:45:52 +0200 (CEST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.68]) by dpdk.org (Postfix) with ESMTP id 449B8255 for ; Mon, 31 Aug 2020 20:45:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C/9DdOeTV/nB3oLax0shq42N1dEwbrF4HsG8yaHHpTg=; b=U8mp+w3DOtjiDylO3PowDM+4t0UZDoIsVQJcvWszBsqn8XY9VSshAjhiOknSz1owFZyJrZ062//PNHDCSCdBzmpD4Ks0A0TCIKi9A4konUZMuzwLoYuHyumxbKR8xotq6BGMIzHo0ZeppvRoqv1sh8mOH2CvsQMQ1le5milrWv4= Received: from MR2P264CA0150.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:1::13) by AM6PR08MB3623.eurprd08.prod.outlook.com (2603:10a6:20b:48::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.22; Mon, 31 Aug 2020 18:45:48 +0000 Received: from VE1EUR03FT057.eop-EUR03.prod.protection.outlook.com (2603:10a6:501:1:cafe::d5) by MR2P264CA0150.outlook.office365.com (2603:10a6:501:1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Mon, 31 Aug 2020 18:45:48 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dpdk.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT057.mail.protection.outlook.com (10.152.19.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Mon, 31 Aug 2020 18:45:47 +0000 Received: ("Tessian outbound 7a6fb63c1e64:v64"); Mon, 31 Aug 2020 18:45:47 +0000 X-CR-MTA-TID: 64aa7808 Received: from 9fb0ed33b230.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 28811A90-DEA0-4DE4-A657-4C77BBA4AB1E.1; Mon, 31 Aug 2020 18:45:42 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9fb0ed33b230.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 31 Aug 2020 18:45:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z6rK8PKK0E8st0JHez3X5D4RUiYZwaf45iUMs9njH1Wcs8f8w9ylHt3O3cuA5I7KG6wpqPs1No4zlY51LMD4xr2vfEFSYuf+h7yiy/KaRHa1TRjNpbpNeXHQjHvadLCnm+Se6whfMtBwYjixKo+eA8hz++z6tAFfDo5G7w4O3lESTvW2RM1iOK9MF4aq4Iwr2BKxP1tz4Ldx6VGY3w7yO5uRcGIRLsGBjwBiOg2oJXSl51L3SZU2PwWAKEBnO4JtHEHDpvoo698vYBH3w7UWnWxIpT5vvVdprz+Y38TUVitkbPrYSzzIOR5cjrjGJ9buz8TL34LqjI0JBeVNLwcz3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C/9DdOeTV/nB3oLax0shq42N1dEwbrF4HsG8yaHHpTg=; b=ZtdJ9IGDb5xeVkh1FGTnEOZ1Uo/Nn7VxhTZfDjKe/nOVeZKM3hsgNrF2kc4hqe4+8coWfrgbQNmwJSNvqRmBVmIKEzlavp6Xra69JHSnW67hiGTfsU/tKpMxUz1mmx44F3zZ9dZjamZ/qnI2SzQU9h0JQN31iz0bzIhmbuyyWFlu+wVp9ALHKrZIqkHIrUvy1PqIV/mz7Bf69eHdeIGOdk5bomghHC3N9pGWP7WckSA69a8psZSKU5zL7ZZCGPu1/RZU2fMzvaasXmuEp607blpPRHoSblhP9wT6GsKwJqckzGitSdd9RxabtGuSS3ufKHpjNgZJuOTEIiVqPyU/Rg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C/9DdOeTV/nB3oLax0shq42N1dEwbrF4HsG8yaHHpTg=; b=U8mp+w3DOtjiDylO3PowDM+4t0UZDoIsVQJcvWszBsqn8XY9VSshAjhiOknSz1owFZyJrZ062//PNHDCSCdBzmpD4Ks0A0TCIKi9A4konUZMuzwLoYuHyumxbKR8xotq6BGMIzHo0ZeppvRoqv1sh8mOH2CvsQMQ1le5milrWv4= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by DB6PR0802MB2552.eurprd08.prod.outlook.com (2603:10a6:4:a2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.25; Mon, 31 Aug 2020 18:45:39 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::408a:40fb:7402:c805]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::408a:40fb:7402:c805%6]) with mapi id 15.20.3326.025; Mon, 31 Aug 2020 18:45:39 +0000 From: Honnappa Nagarahalli To: Phil Yang , Diogo Behrens CC: "dev@dpdk.org" , nd , Honnappa Nagarahalli , nd Thread-Topic: [PATCH] librte_eal: fix mcslock hang on weak memory Thread-Index: AQHWe4pZOqSFXnd9v02KDV0dJx5bZ6lKKsYAgAAFG2CAAxHWAIAFVD2w Date: Mon, 31 Aug 2020 18:45:39 +0000 Message-ID: References: <20200826092002.19395-1-diogo.behrens@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 7C0212FD7DD19443BCC42112ABDA7665.0 x-checkrecipientchecked: true Authentication-Results-Original: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [70.112.90.121] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 943c3b8f-166f-4fd2-b046-08d84dde1387 x-ms-traffictypediagnostic: DB6PR0802MB2552:|AM6PR08MB3623: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Zfju9CWqOVwoyxmx4KFgH+UWm0HjEBmHO4uoqLHo8BJydGKwb/QzJFWv/EjKbiwG6vDlU/lwEtKsZcW0yavSqwyx1xxLQQxisncDs/wnizbtqsoTRHHt81KSrR8sOzIuhCip3ZJ5rnK3pnldnX8wR2XwIGdoLxeNaLWfn4P4UtOBvenmbdQsM0G2G1S/I3Qt5gvS4QEWHo8jCwE0IhcEjJ6wAIZGknrNOJgqrBXDPrCuQZI1vPM8EyL7cSQDPyyx162LdNrPXlWQFE4FsCCVJEJRjS+tgbQhYsW6tuwF8uUgFXxOXydEo8S3eM3ryeafgJ70AEDpo/zzkTzaXnR4uNCR64XN8vTwzqqQJgqlv+6/czgG163ifPVd7PbhJRMiIKTISjulJcJXbjJxYQIDgB12uk3JKVIuXNUgZubzAhpHA3EN7pax7Kto6T73wUcFp6D8r5PlqWblmghwml+F5g== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(346002)(376002)(136003)(33656002)(83380400001)(186003)(7696005)(71200400001)(4326008)(66556008)(66476007)(316002)(66946007)(64756008)(54906003)(66446008)(86362001)(76116006)(52536014)(110136005)(6506007)(53546011)(26005)(478600001)(966005)(9686003)(8936002)(8676002)(55016002)(5660300002)(2906002)(87944003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: i+CN+cxJTUsOp3NlSdEBvGQdHi5tTBJvEBAOOWSWQysPH9tUzyY2q5wNgwmsPRfsynOh/+pPEKuxQo6aNlKApaYfWHf4K2k6gH2Xych36rXNl0qVrcySPC7MDQ2pTyk6eLR/H5D0bpyj2PFJk2aS8T6WF5jKsVOkDx8N02vH9lSSYx5lRmqZZ6lVBuFbcsUqtR+g/fU+5ag6L0iI6jLI1haEpE3vzCT7a6gwsEMHXknxq61epVCKlPqxsWMRr/KLHJ1pzD5JRbGg1eUWmfmoWnUqgONrCZq5NEcVCVUGSLfj2KDG1kJOWlz/c+Us4owzqT1a9I2WwWDkACn29Z9be6h6MVwQltkAnLsDYOwSG/byFraRQCstjwyfmaidLnv6QE/X42zqxb0jcF3CYpE2LJjItv623ZM2ilz6lyJD9Fgz1gFl/crR+JepKYcyui6BUVN2FUZTZSB0Zvslc3FIW6AsqEsj1S9uDJi4v42pqdjtSQApduTb/F6u8OdT4TEEnbBDNEpvmh2wFU3cM2C0veIKMGVRji6MDgBmwn5Jd5m8LLFMrpGhKQUuPna6hjUK6WgZe/YZLIysKWERlP2PitDLetLUk+EoW0yY7oWL6ZToR3fuiwW4x3NPsUV+RosOD/iJ2A9zm2HBDu7ci3/uoA== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2552 Original-Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: bb8410e1-0380-426a-b5a5-08d84dde0ec2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uyxkh0bO5rjTOxsaPNXJpGUmR5ayZZFbdUiTtHesg7o1hMVvTr7V7r0ZFPV/svuoifGpM8XtYTHsKXXNgnnfTdLOssCtBdSyV0TdknXJUbw2VH5ZG3SuFQz8uEXO/ZS5lenwWvkg1ZHmI6efScxUUcK8vzHR0Ao2nJ2tdwuTf4XOsf35GZ/fuUwnSUNz41canz/rNHlJ4QTgAWBs6zJTi1BP8kIXtGz1yPi9xc36RY9k5V56vwc0wJnlg01wjQ//iw1Unf5QxGY/wxv1Vmlsic3lOpRNpKewbJdVKAK1xykXRlXsSLMCj8L0+pKhAuwOVCPEcNf6ojLlbiqH7ATCP3Imq/2EPhISEl2kaLbb7GlC6kJu1fdqTuh2Q4aUCRieTn2UCfPjML+C9oImGQMgQ2kyNI4Ay6bU7gtaCRI/bTtpZUjBDZcKT47EPAmz2XCfGQTmowyL4H6UxTmKGlwBfhYnw2SSURZ9M8Pw5y+8FKkVE7oCO5ylOwaWyiKQj82Q X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(46966005)(33656002)(9686003)(82740400003)(8676002)(52536014)(83380400001)(70586007)(70206006)(55016002)(356005)(81166007)(8936002)(5660300002)(82310400002)(4326008)(6506007)(110136005)(53546011)(966005)(54906003)(7696005)(478600001)(186003)(26005)(36906005)(316002)(2906002)(47076004)(336012)(86362001)(87944003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2020 18:45:47.7523 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 943c3b8f-166f-4fd2-b046-08d84dde1387 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3623 Subject: Re: [dpdk-dev] [PATCH] librte_eal: fix mcslock hang on weak memory X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Diogo, Thanks for your explanation. As documented in https://developer.arm.com/documentation/ddi0487/fc =A0B2.9= .5 Load-Exclusive and Store-Exclusive instruction usage restrictions: " Between the Load-Exclusive and the Store-Exclusive, there are no explicit= memory accesses, preloads,=20 direct or indirect System register writes, address translation instructions= , cache or TLB maintenance instructions, exception generating instructions, exception returns, or indi= rect branches." [Honnappa] This is a requirement on the software, not on the micro-architec= ture. We are having few discussions internally, will get back soon. So it is not allowed to insert (1) & (4) between (2, 3). The cmpxchg operat= ion is atomic. Thanks, Phil Yang > -----Original Message----- > From: Diogo Behrens > Sent: Thursday, August 27, 2020 4:57 PM > To: Phil Yang > Cc: mailto:dev@dpdk.org; nd ; Honnappa Nagarahalli > > Subject: RE: [PATCH] librte_eal: fix mcslock hang on weak memory >=20 > Hi Phil, >=20 > thanks for taking a look at this. Indeed, the cmpxchg will have release > semantics, but implicit barriers do not provide the same ordering guarant= ees > as DMB ISH, ie, atomic_thread_fence(__ATOMIC_ACQ_REL). >=20 > Let me try to explain the scenario. Here is a pseudo-ARM assembly with th= e > instructions involved: >=20 > STR me->locked=A0 =3D 1=A0=A0 // 1: initialize the node > LDAXR pred =3D tail=A0 // 2: cmpxchg > STLXR tail =3D me=A0=A0=A0 // 3: cmpxchg > STR pred->next =3D me // 4: the problematic store >=20 > Now, ARM allows instruction 1 and 2 to be reordered, and also instruction= s 3 > and 4 to be reordered: >=20 > LDAXR pred =3D tail=A0 // 2: cmpxchg=A0 (acquires can be moved up) > STR me-> locked =3D 1=A0=A0 // 1: initialize the node > STR pred->next =3D me // 4: the problematic store > STLXR tail =3D me=A0=A0=A0 // 3: cmpxchg (releases can be moved down) >=20 > And since stores 1 and 4 can be reordered too, the following execution is > possible: >=20 > LDAXR pred =3D tail=A0 // 2: cmpxchg > STR pred->next =3D me // 4: the problematic store > STR me-> locked =3D 1=A0=A0 // 1: initialize the node > STLXR tail =3D me=A0=A0=A0 // 3: cmpxchg >=20 > In this subtle situation, the locking-thread can overwrite the store to n= ext- > >locked of the unlocking-thread (if it occurs between 4 and 1), and > subsequently hang waiting for me->locked to become 0. >=20 > We couldn't reproduce this with our available hardware, but we > "reproduced" it with the RMEM model checker, which precisely models the > ARM memory model (https://github.com/rems-project/rmem). The GenMC > model checker (https://github.com/MPI-SWS/genmc) also finds the issue, > but its intermediate memory model is slightly more general than the ARM > model. >=20 > The release attached to store (4) prevents (1) to reordering with it. >=20 > Please, let me know if that makes sense or if I am missing something. >=20 > Thanks, > -Diogo >=20 > -----Original Message----- > From: Phil Yang [mailto:Phil.Yang@arm.com] > Sent: Wednesday, August 26, 2020 12:17 PM > To: Diogo Behrens > Cc: mailto:dev@dpdk.org; nd ; Honnappa Nagarahalli > ; nd > Subject: RE: [PATCH] librte_eal: fix mcslock hang on weak memory >=20 > Diogo Behrens writes: >=20 > > Subject: [PATCH] librte_eal: fix mcslock hang on weak memory > > > >=A0=A0=A0=A0 The initialization me->locked=3D1 in lock() must happen bef= ore > >=A0=A0=A0=A0 next->locked=3D0 in unlock(), otherwise a thread may hang f= orever, > >=A0=A0=A0=A0 waiting me->locked become 0. On weak memory systems (sHi Pu= ch as > ARMv8), > >=A0=A0=A0=A0 the current implementation allows me->locked=3D1 to be reor= dered with > >=A0=A0=A0=A0 announcing the node (pred->next=3Dme) and, consequently, to= be > >=A0=A0=A0=A0 reordered with next->locked=3D0 in unlock(). > > > >=A0=A0=A0=A0 This fix adds a release barrier to pred->next=3Dme, forcing > >=A0=A0=A0=A0 me->locked=3D1 to happen before this operation. > > > > Signed-off-by: Diogo Behrens > > --- > >=A0 lib/librte_eal/include/generic/rte_mcslock.h | 9 ++++++++- > >=A0 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/lib/librte_eal/include/generic/rte_mcslock.h > > b/lib/librte_eal/include/generic/rte_mcslock.h > > index 2bef28351..ce553f547 100644 > > --- a/lib/librte_eal/include/generic/rte_mcslock.h > > +++ b/lib/librte_eal/include/generic/rte_mcslock.h > > @@ -68,7 +68,14 @@ rte_mcslock_lock(rte_mcslock_t **msl, > rte_mcslock_t > > *me) > >=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0*/ > >=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 return; > >=A0 =A0=A0=A0=A0=A0=A0=A0 } > > -=A0=A0=A0=A0=A0=A0 __atomic_store_n(&prev->next, me, __ATOMIC_RELAXED)= ; > > +=A0=A0=A0=A0=A0 /* The store to me->next above should also complete be= fore the > > node is > > +=A0=A0=A0=A0=A0 * visible to predecessor thread releasing the lock. He= nce, the store > > +=A0=A0=A0=A0=A0 * prev->next also requires release semantics. Note tha= t, for > > example, > > +=A0=A0=A0=A0=A0 * on ARM, the release semantics in the exchange operat= ion is not > > +=A0=A0=A0=A0=A0 * strong as a release fence and is not sufficient to e= nforce the > > +=A0=A0=A0=A0=A0 * desired order here. >=20 >=20 > Hi Diogo, >=20 > I didn't quite understand why the exchange operation with ACQ_REL > memory ordering is not sufficient. > It emits 'stlxr' on armv8.0-a and 'swpal' on armv8.1-a (with LSE support)= . > Both of these two instructions contain a release semantics. >=20 > Please check the URL for the detail. > https://gcc.godbolt.org/z/Mc4373 >=20 > BTW, if you captured a deadlock issue on your testbed, could you please > share your test case here? >=20 > Thanks, > Phil >=20 >=20 > > +=A0=A0=A0=A0=A0 */ > > +=A0=A0=A0=A0=A0 __atomic_store_n(&prev->next, me, __ATOMIC_RELEASE); > > > >=A0 =A0=A0=A0=A0=A0=A0=A0 /* The while-load of me->locked should not mov= e above the > previous > > =A0=A0=A0=A0=A0=A0=A0=A0 =A0* store to prev->next. Otherwise it will ca= use a deadlock. Need a > > -- > > 2.28.0 > >