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 165FAA04B1; Fri, 28 Aug 2020 11:20:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 55C2B1C0D0; Fri, 28 Aug 2020 11:20:08 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70054.outbound.protection.outlook.com [40.107.7.54]) by dpdk.org (Postfix) with ESMTP id 8D1881C0CA for ; Fri, 28 Aug 2020 11:20:07 +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=A+wLCdI849CTaxawYirQjMgigwHmLn7Meux/XvPa1Qo=; b=l1TBsk5Dm18U61ejAk20TAFOAsEerNJivHy5bHTAcww933KQCMBp4Kkqnd45AwJz7BPQU6J0I2J0lFTZH0yE/j2i/pdDChCxT2NP3VJynuPgE+Zeo63tvJFrzay6mW+9VtDnOaEKE08oOJH+vxcTlGCnqFpCcbqfFDTqJxFw9GE= Received: from AM6P194CA0078.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::19) by AM5PR0802MB2481.eurprd08.prod.outlook.com (2603:10a6:203:a0::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25; Fri, 28 Aug 2020 09:20:06 +0000 Received: from VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8f:cafe::72) by AM6P194CA0078.outlook.office365.com (2603:10a6:209:8f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Fri, 28 Aug 2020 09:20:05 +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 VE1EUR03FT044.mail.protection.outlook.com (10.152.19.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Fri, 28 Aug 2020 09:20:05 +0000 Received: ("Tessian outbound 7fc8f57bdedc:v64"); Fri, 28 Aug 2020 09:20:05 +0000 X-CR-MTA-TID: 64aa7808 Received: from 10327ea6f79c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BF1144A6-4AC0-4C22-A3F1-DA772DA72CF5.1; Fri, 28 Aug 2020 09:20:00 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 10327ea6f79c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 28 Aug 2020 09:20:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K8xcf8IGUDNmMp7+iVmpGDbalGHIaGJKJhnSUJvZJqM5bALszZ53zQBu6sSVaF4SAnjXin7SRmefyT+I/D5FDlQCjlGyzpGmKw5WMJ0q+DWuYRxMErCk9MrFfjKA/lOqK7LrQJk3PvkvWIS3T98Bphq+eAfFwh97vJr80ivMbVsVYHvMn9Gx406B/Iw58h+NHQNSYqfhlUypijn1MC8h2QHPqN/EM7/cHNIwp0CGmxC9u7Ud8aHey5K2mgaAq8BUlKbQdSoPE2oxlKuMF1/F17vNFTPUZ+RvG0Jb0XBF1htTVkdTFzN3VRZTXykJQTbzALiAqiucYZvs8DFeuaD9og== 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=A+wLCdI849CTaxawYirQjMgigwHmLn7Meux/XvPa1Qo=; b=jHWoz5wxMMqi+GaAIGdVajHtwdGX8csOtNt5gCyKSVOnD4gvDdnzqtSniYfyuIk8/tsDHoc2Yvp/B/cOMn4J0Tvfc3L/ZenRcY2dy0ywid2diH9sqOC1DBWggHAbBuzM9GqfovvfyBVcHnQfIqmxYCcJTWIgUIsvMrb//P9i6tyZUDpNfM4lBbrMFNYXyDN4Jx1BkT6gfdOZPv+mXq7fu/Jrj8/Difx8hpyzQMZ1nNcFhpVs63dI9g9iE3xojfiPCwFqKOpJbLdUqwLnyU8T9FTqC72BoFrXDCJdU2xXCXPFOgUmka9glCxb7COC4ebjnFus8Yo61r9LpH9bDL2ZdQ== 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=A+wLCdI849CTaxawYirQjMgigwHmLn7Meux/XvPa1Qo=; b=l1TBsk5Dm18U61ejAk20TAFOAsEerNJivHy5bHTAcww933KQCMBp4Kkqnd45AwJz7BPQU6J0I2J0lFTZH0yE/j2i/pdDChCxT2NP3VJynuPgE+Zeo63tvJFrzay6mW+9VtDnOaEKE08oOJH+vxcTlGCnqFpCcbqfFDTqJxFw9GE= Received: from DB7PR08MB3865.eurprd08.prod.outlook.com (2603:10a6:10:74::25) by DBAPR08MB5606.eurprd08.prod.outlook.com (2603:10a6:10:1a7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Fri, 28 Aug 2020 09:19:59 +0000 Received: from DB7PR08MB3865.eurprd08.prod.outlook.com ([fe80::519c:72bd:e189:625b]) by DB7PR08MB3865.eurprd08.prod.outlook.com ([fe80::519c:72bd:e189:625b%7]) with mapi id 15.20.3326.023; Fri, 28 Aug 2020 09:19:59 +0000 From: Phil Yang To: Diogo Behrens CC: "dev@dpdk.org" , nd , Honnappa Nagarahalli , nd Thread-Topic: [PATCH] librte_eal: fix mcslock hang on weak memory Thread-Index: AQHWe4pZeMmgY2mDiEqkB/VtKH/xk6lKKsYAgAF+IQCAAZU3UA== Date: Fri, 28 Aug 2020 09:19:58 +0000 Message-ID: References: <20200826092002.19395-1-diogo.behrens@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 15F070DCA2E3624F9A84E9F90F5E7AC3.0 x-checkrecipientchecked: true Authentication-Results-Original: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [203.126.0.113] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7e8fb074-f89f-47f5-5d73-08d84b338d1f x-ms-traffictypediagnostic: DBAPR08MB5606:|AM5PR0802MB2481: 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: 5yD+M7qM9yjMO3O4/NJXviua1nT2HADh6CmBDCwVrNUTylylhTvSV0c6uCeVrsejFIrSGG8pgn4+qj2fwoVlCI4BusABWWcdLucMbcKsKDu0QEsu2/YkoK5+8TbyY3imBiwCgHMIB9yzOLVtMnbTlclMadgEOatWIBQbxSYfOB80jfJ+LS5bZLxgNLfxyBl90btBYPEouMiwGTcUvsTkXAjd0UzZ/visdWmXOiCpWjOIycZkFpw8zRqJ86HkZovl7x26ikM7JZgiPPAjjSX+MOeDfnyibMX9hQh33wrjCx8SLmgVFaiT1acfFpohwnobVafonvOWGFpVqfhBX0Q9EGye28bBn8TDFSfov9JRNWS+v+OTXnB1zoVHZz4qmkAkqj1p3xEsxdPd26aQqKofmXOerUTdEkGIpvgSdZ22kG7gd3dALy3adh7NTqlrzHgFlDcr3b9GfmlwsM74kGL0lQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3865.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(2906002)(86362001)(166002)(64756008)(186003)(4326008)(6916009)(66476007)(76116006)(54906003)(66446008)(66946007)(66556008)(26005)(9326002)(966005)(52536014)(8676002)(53546011)(7696005)(33656002)(8936002)(83380400001)(9686003)(55016002)(6506007)(478600001)(71200400001)(316002)(5660300002)(87944003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PfDVd17kY2rHpzNJ+HRbHtUIeOEVn60RJPxkhD0kQfPvVVqvKZZLLMMsbe5RnJpFJroeEOouuLqdFDUNwFZw186ogm4cyv4HJhSQdiqlcYXS5rdBPQ8irVK7Z1emWRfA8p7HDWVXLU371GI2yAtVqSdaM+PupgtkkbVm2BucZ50QMqOSxVJh9odX8DVsadIaUn7yFlGbzEcleAlimFL1LRmyvQbURvfKvtUMWCfJPq0SpzjDrTUOgH6iZi4axuuAO4bk6heWYujqKetC4XBjyO9sz8xaoSahhhhhRHy4kk9pq5mqyIox10Q2bzT4fSzrRdCzq3iZ9Ph7yPcMhYHXg8y9RR3KLz5OWHY6eoYSA859SccA9tBeNcMN/LRkiLxE8waDyIZUxVBAE+bnTGKpWOEmHJdIQpWQpGP1kgFIbh18z2/iqFklbbZplHB8+ZEOg1zuJxd0lB9mpPLtPME63tnMm6t97qe6TeyHi8RHL9HC3OP7mQAPZmfxDxmLAgGrwIj7xoO2fuRvDBHmvlMHFBpjiaYjXp59IR/rayb8Xzc0uQPDcgaLxVEP6UhyJlL9DLMJp9614up07qXw8OBxNPhdRKqie2qFDZjh2kmPSlfJmbOF/9XvPEbp/lupZz0xRq5Tc7+Nh4Vr+LZe9W6vHQ== MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5606 Original-Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 33c2b514-e5e9-4e26-4dad-08d84b338937 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lpClt+XE6x5onINAABHnGHT6Zz2fb6lq0Hn885C0gAXW5Sv4bUkhDvUaB+jVrpr6oYVGvHICIKFhWehiCMd15ehx5B1M4WDOTv2dEApXZPOMao/b5x22p1Dc8EcP8FnSpwDDjWweIQSNfgpn2iQmwGJKitp0DPdjRrIAiEU/Lcc6e8EH5YLqBOAGu6RTjrIcg+NhYe8NkyJuFHxO6Wvt9e0aCGlgVHvbBmvio4Qn7SrgmyPN8EQrV3cVOnyRPLKlLMegknCIOCpU/l34uBL+5QHmTewG3HceDiobg6qfru/5mnC/j4eyKOqItdKqdKmDtDivfEDbjbe+16kTABaxqE68qo2baZE/jaoCanHj5AjKbFxJikpqAdRP2M9uINS0t6k6cVtPPRrGSxb/MNHCEqSZsDxpjFI1lynOK2qhdErcHkIIgoo+OLfdAoWLqo8JTGGsKeDlQiSW+1jXTukiDHK9E9jZmIRmamlkVI+iCvQNswX3i2yZbJJnA4HL9nmk 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)(376002)(396003)(39860400002)(346002)(136003)(46966005)(7696005)(54906003)(336012)(26005)(53546011)(6506007)(36906005)(33656002)(70586007)(2906002)(52536014)(8676002)(966005)(186003)(30864003)(83380400001)(9686003)(47076004)(316002)(166002)(82310400002)(70206006)(6862004)(356005)(478600001)(86362001)(5660300002)(8936002)(4326008)(9326002)(55016002)(81166007)(82740400003)(87944003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2020 09:20:05.4494 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7e8fb074-f89f-47f5-5d73-08d84b338d1f 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: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2481 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 Arm ARM B2.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, direct or indirect System register writes, address translation instructions= , cache or TLB maintenance instructions, exception generating instructions, exception returns, or indi= rect branches." 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: dev@dpdk.org; nd ; Honnappa Nagarahalli > > Subject: RE: [PATCH] librte_eal: fix mcslock hang on weak memory > > Hi Phil, > > 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). > > Let me try to explain the scenario. Here is a pseudo-ARM assembly with th= e > instructions involved: > > STR me->locked =3D 1 // 1: initialize the node > LDAXR pred =3D tail // 2: cmpxchg > STLXR tail =3D me // 3: cmpxchg > STR pred->next =3D me // 4: the problematic store > > Now, ARM allows instruction 1 and 2 to be reordered, and also instruction= s 3 > and 4 to be reordered: > > LDAXR pred =3D tail // 2: cmpxchg (acquires can be moved up) > STR me-> locked =3D 1 // 1: initialize the node > STR pred->next =3D me // 4: the problematic store > STLXR tail =3D me // 3: cmpxchg (releases can be moved down) > > And since stores 1 and 4 can be reordered too, the following execution is > possible: > > LDAXR pred =3D tail // 2: cmpxchg > STR pred->next =3D me // 4: the problematic store > STR me-> locked =3D 1 // 1: initialize the node > STLXR tail =3D me // 3: cmpxchg > > 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. > > 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. > > The release attached to store (4) prevents (1) to reordering with it. > > Please, let me know if that makes sense or if I am missing something. > > Thanks, > -Diogo > > -----Original Message----- > From: Phil Yang [mailto:Phil.Yang@arm.com] > Sent: Wednesday, August 26, 2020 12:17 PM > To: Diogo Behrens > > Cc: dev@dpdk.org; nd >= ; Honnappa Nagarahalli > >; nd <= nd@arm.com> > Subject: RE: [PATCH] librte_eal: fix mcslock hang on weak memory > > Diogo Behrens >= writes: > > > Subject: [PATCH] librte_eal: fix mcslock hang on weak memory > > > > The initialization me->locked=3D1 in lock() must happen before > > next->locked=3D0 in unlock(), otherwise a thread may hang forever, > > waiting me->locked become 0. On weak memory systems (sHi Puch as > ARMv8), > > the current implementation allows me->locked=3D1 to be reordered wi= th > > announcing the node (pred->next=3Dme) and, consequently, to be > > reordered with next->locked=3D0 in unlock(). > > > > This fix adds a release barrier to pred->next=3Dme, forcing > > me->locked=3D1 to happen before this operation. > > > > Signed-off-by: Diogo Behrens > > > --- > > lib/librte_eal/include/generic/rte_mcslock.h | 9 ++++++++- > > 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) > > */ > > return; > > } > > - __atomic_store_n(&prev->next, me, __ATOMIC_RELAXED); > > + /* The store to me->next above should also complete before the > > node is > > + * visible to predecessor thread releasing the lock. Hence, the s= tore > > + * prev->next also requires release semantics. Note that, for > > example, > > + * on ARM, the release semantics in the exchange operation is not > > + * strong as a release fence and is not sufficient to enforce the > > + * desired order here. > > > Hi Diogo, > > 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. > > Please check the URL for the detail. > https://gcc.godbolt.org/z/Mc4373 > > BTW, if you captured a deadlock issue on your testbed, could you please > share your test case here? > > Thanks, > Phil > > > > + */ > > + __atomic_store_n(&prev->next, me, __ATOMIC_RELEASE); > > > > /* The while-load of me->locked should not move above the > previous > > * store to prev->next. Otherwise it will cause a deadlock. Ne= ed a > > -- > > 2.28.0 > >