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 6F824A052B; Tue, 28 Jul 2020 21:04:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 43E6A2B86; Tue, 28 Jul 2020 21:04:59 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id BA402255 for ; Tue, 28 Jul 2020 21:04:57 +0200 (CEST) IronPort-SDR: 52sKQ4g+U2HlQJ7QNjesEFhWQahjyoGcNQRXlOt5NfTjxD5x2R/bwBy/bdrIfW8oDM66ezCNyT bXxdoW91gg+A== X-IronPort-AV: E=McAfee;i="6000,8403,9696"; a="169413622" X-IronPort-AV: E=Sophos;i="5.75,407,1589266800"; d="scan'208";a="169413622" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2020 12:04:56 -0700 IronPort-SDR: NF27k18uaoK8zfWl9OTXJ48G6vqjg6eGG2wfbKJvYen1O+4B4yBZ6MhV2WpZgEVW3lVImmba5R 2EqrOEvsN/XQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,407,1589266800"; d="scan'208";a="464585110" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga005.jf.intel.com with ESMTP; 28 Jul 2020 12:04:56 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 28 Jul 2020 12:04:55 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 28 Jul 2020 12:04:55 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.57) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 28 Jul 2020 12:04:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RksdPNTG0f8aWYcC+TmwOoyfiiODMwpi7rSkNwVBUEFNp+XSBAOS/DAXhUVAtTLu3x6BndOqx6AKpxIKxnktWp6GsYODz4IBjhAmjTJP7Ljv4+PRUhFdBaV+rMOWEKfYvXktfVa5lkOxGeHSbmHT5FJjIvu364/Zs4kKayKLmwZNQtSqH0M8pMIhKFYBmDpv4tl6epzXbrmoERze7hGgZHo4KUtXERde38nvDUU0KCndRev4d2ecrQekDRxVH4+a3pA5xy7hiqN5BEpMFXaNHzY85sp0XRtyM6ddQ+S6oyfhkZxaX0yBW2Paxkntz6c5998g5ucrOzhRgvi360p7ow== 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=APfLy5+mATP8orCW/pBakPAx5aPWQFkcwnMab5MNKGA=; b=k0sTDOmf8Qhh1jRTLZbY1aq+QZ34INzB4GKDzawjvU9cdTX+NdD4PbvnwHSFmUHzaxhu5pSaj97f3buq1Ydy6Rz+PFZfhOgxUDm9hkTrydAgoW9Uku6KzCSGPph1FuQ1ELdNV258KRaO66YIExnixcZ2V+xwZwenVpPo99FHh5/PxnG+L8i62Vf5XoJwAULC7qesY3EbmPmQ/CeLPUtTBcrCfYijcRW672nBU0a+GG63sqaJ5N+kj8siNd0mSrO5VdKHDCjj8MC48isVYox6TyoQmZzbJxwJNn+X+TA82EMTsnr9OLa3G53vj0BZHJxyh5criAnd6/9IjSOfMOdstA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=APfLy5+mATP8orCW/pBakPAx5aPWQFkcwnMab5MNKGA=; b=eb64yHVWCCzOZ2jtz+RBLl6LgvgvnINvrbJY0N0wjHa0ffWiW2A5GvnmcclhFTy4ZuPWeUvsYsN0CTMYMWeFAHDLrJqu2/7ICzQYdDDI2mdZES5rwm2ScJf1nfHgIY36g9Sp5uqQ8M8eykkS+7B7xvdeRkl6HmA+0J3vGW2rL54= Received: from CY4PR1101MB2118.namprd11.prod.outlook.com (2603:10b6:910:1f::10) by CY4PR11MB1912.namprd11.prod.outlook.com (2603:10b6:903:127::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Tue, 28 Jul 2020 19:04:53 +0000 Received: from CY4PR1101MB2118.namprd11.prod.outlook.com ([fe80::410b:7807:181:1620]) by CY4PR1101MB2118.namprd11.prod.outlook.com ([fe80::410b:7807:181:1620%4]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 19:04:52 +0000 From: "Carrillo, Erik G" To: Sarosh Arif , "dev@dpdk.org" , "rsanford@akamai.com" CC: "h.mikita89@gmail.com" , Stephen Hemminger Thread-Topic: [PATCH v3] lib/librte_timer:fix corruption with reset Thread-Index: AQHWVogA5XdjGn6SJU6je7GIbQzIUKkdX+Nw Date: Tue, 28 Jul 2020 19:04:52 +0000 Message-ID: References: <20200707090320.2463-1-sarosh.arif@emumba.com> <20200710065954.4937-1-sarosh.arif@emumba.com> In-Reply-To: <20200710065954.4937-1-sarosh.arif@emumba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: emumba.com; dkim=none (message not signed) header.d=none;emumba.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [136.49.135.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b8be74a-34e5-40c2-ef42-08d833291c06 x-ms-traffictypediagnostic: CY4PR11MB1912: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YPcF6cyO/anZyJG3qyxJaP8pP7qniwg6k/UqEbiJxrgo7ltGvQJ02E1FxvPBH9OeG1Ont2NFgf1xv9z3Pq2btvqQYOeT01P3viumzX+6LCZUoaRa+oq0BxRo+tG6RPoordNOQVyFbKk/8O6aJ8CR75XkVD25NQ/rSGE7u8YQagnArC2Y10taXsXvsze5aGBLl8r/2J6sxGBDZ9h0YZGtwYWUVb01g0G2tOixpDU26FEhG6Nl+rAT29jISmF3c41ptSEuublJaGH233+qKyrmCfMzkPgamfdnoTRkonQyyHKzcazLhHLFqV5waDwlLZP7UDAgi8VeVdGlq7DvrNzDgm3UcgHi9nZr5ejBt8xYuB43wIsUIkVnciqz4kApqh9cDdWTcPx/oIEdxKGfXbpbRw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1101MB2118.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(376002)(346002)(396003)(136003)(52536014)(66946007)(26005)(5660300002)(66446008)(33656002)(76116006)(66476007)(66556008)(54906003)(64756008)(316002)(110136005)(86362001)(2906002)(6506007)(53546011)(7696005)(478600001)(8936002)(9686003)(83380400001)(8676002)(186003)(4326008)(71200400001)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: lvrE7R1daaq5fTF9c6lI7GsWKELJHpo1Uhq7IG4TZMR/JFkmMq1OEXUaqxSZWLHuQjX85Y3WfBoEiPr/U334fUmtM24wv88jOagXpI5da8ViC8CBpJ0GOHHnYfAiXcH2cpeSgWGSIgAmrnqrdPOGpURbpZ7qRU5H16+MNFJPvFgoLHCJWKYKh0TQjviAPbt+F9QghoEGXJ+FKebX+Aoo/CLHKZfpItxkJg8dDwntFm6F8fXA6TZdA+FWqX2rWB8IR1vMHnJvZsaJFwf2wfm71OqAO/Av16GnfVo/9qBNg2CxhrjQ919V4MSj96kDI6uKiSjbx8hhtgPMqxOUpUHgPx3jXpNpuRbrET9jp6yeGmY/lH6QLUKCd3eTiGdw6VnL9DA7YRAUXBCi5YMZQavdUzIopeEHvb6nXqMTmCNgmE1lxa6QLx/cFYyqIh40aPOblExuaLdDC//oOwoIF4M9ag0zw6hOydXZR+SuG0HS21w= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR1101MB2118.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b8be74a-34e5-40c2-ef42-08d833291c06 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 19:04:52.8827 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SCnVHs0LeAlepqWSw5/aqErI17UYbw1oryrDhOBA20ACJ92l1HiZF7NqldKQI3R8ILBXBXAfuhM9qMWLhUu4UFsyGCznRQkSPS+Rvu5k7po= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1912 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3] lib/librte_timer:fix corruption with reset 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 Sarosh, Some comments in-line: > -----Original Message----- > From: Sarosh Arif > Sent: Friday, July 10, 2020 2:00 AM > To: rsanford@akamai.com; Carrillo, Erik G ; > dev@dpdk.org > Cc: stable@dpdk.org; Sarosh Arif ; > h.mikita89@gmail.com > Subject: [PATCH v3] lib/librte_timer:fix corruption with reset The subject is misleading - perhaps wording closer to the title of the Bugz= illa bug would be more helpful. >=20 > If the user tries to reset/stop some other timer in it's callback functio= n, which > is also about to expire, using rte_timer_reset_sync/rte_timer_stop_sync t= he > application goes into an infinite loop. This happens because > rte_timer_reset_sync/rte_timer_stop_sync loop until the timer resets/stop= s > and there is check inside timer_set_config_state which prevents a running > timer from being reset/stopped by not it's own timer_cb. Therefore > timer_set_config_state returns -1 due to which rte_timer_reset returns -1 > and rte_timer_reset_sync goes into an infinite loop. >=20 > The soloution to this problem is to return -1 from > rte_timer_reset_sync/rte_timer_stop_sync in case the user tries to > reset/stop some other timer in it's callback function. >=20 > Bugzilla ID: 491 > Fixes: 20d159f20543 ("timer: fix corruption with reset") > Cc: h.mikita89@gmail.com > Signed-off-by: Sarosh Arif > --- > v2: remove line continuations > v3: separate code and declarations > --- > lib/librte_timer/rte_timer.c | 26 ++++++++++++++++++++++++-- > lib/librte_timer/rte_timer.h | 4 ++-- > 2 files changed, 26 insertions(+), 4 deletions(-) >=20 > diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c = index > 6d19ce469..0cd3e2c86 100644 > --- a/lib/librte_timer/rte_timer.c > +++ b/lib/librte_timer/rte_timer.c > @@ -576,14 +576,24 @@ rte_timer_alt_reset(uint32_t timer_data_id, struct > rte_timer *tim, } >=20 > /* loop until rte_timer_reset() succeed */ -void > +int > rte_timer_reset_sync(struct rte_timer *tim, uint64_t ticks, > enum rte_timer_type type, unsigned tim_lcore, > rte_timer_cb_t fct, void *arg) > { > + struct rte_timer_data *timer_data; > + TIMER_DATA_VALID_GET_OR_ERR_RET(default_data_id, > timer_data, -EINVAL); > + > + if (tim->status.state =3D=3D RTE_TIMER_RUNNING && > + (tim->status.owner !=3D (uint16_t)tim_lcore || > + tim !=3D timer_data->priv_timer[tim_lcore].running_tim)) > + return -1; > + As I understand it, Bugzilla 491 describes two scenarios where a hang can o= ccur: 1. A timer's callback tries to synchronously reset/stop another timer in t= he same run list 2. A timer's callback tries to synchronously reset/stop another timer in a= different run list whose lcore happens to be running a timer callback that= is synchronously resetting/stopping a timer in the first run list The if condition from the patch above can be broken up as: (tim->status.state =3D=3D RTE_TIMER_RUNNING && tim->status.owner =3D=3D (u= int16_t)lcore_id && tim !=3D timer_data->priv_timer[lcore_id].running_tim) And (tim->status.state =3D=3D RTE_TIMER_RUNNING && tim->status.owner !=3D (ui= nt16_t)lcore_id) This second condition could be transient and doesn't necessarily identify s= cenario (2) above. In this case, the *_sync() calls could fail unnecessari= ly. Offhand, I'm not seeing a way to more precisely detect scenario 2 above. I= 'm wondering if some kind of a timeout parameter could be added to avoid ha= nging instead. Thoughts? As Stephen mentioned in another response, it looks like this will require a= n API change. I believe this can be announced in the next release via doc/= guides/rel_notes/deprecation.rst. Then, the new API can be added in the ne= xt ABI-breaking release, possibly with versioned symbols (http://doc.dpdk.o= rg/guides/contributing/abi_versioning.html#versioning-macros). =20 Thanks, Erik > while (rte_timer_reset(tim, ticks, type, tim_lcore, > fct, arg) !=3D 0) > rte_pause(); > + > + return 0; > } >=20 > static int > @@ -642,11 +652,23 @@ rte_timer_alt_stop(uint32_t timer_data_id, struct > rte_timer *tim) } >=20 > /* loop until rte_timer_stop() succeed */ -void > +int > rte_timer_stop_sync(struct rte_timer *tim) { > + struct rte_timer_data *timer_data; > + unsigned int lcore_id =3D rte_lcore_id(); > + > + TIMER_DATA_VALID_GET_OR_ERR_RET(default_data_id, > timer_data, -EINVAL); > + > + if (tim->status.state =3D=3D RTE_TIMER_RUNNING && > + (tim->status.owner !=3D (uint16_t)lcore_id || > + tim !=3D timer_data->priv_timer[lcore_id].running_tim)) > + return -1; > + > while (rte_timer_stop(tim) !=3D 0) > rte_pause(); > + > + return 0; > } >=20 > /* Test the PENDING status of the timer handle tim */ diff --git > a/lib/librte_timer/rte_timer.h b/lib/librte_timer/rte_timer.h index > c6b3d450d..392ca423d 100644 > --- a/lib/librte_timer/rte_timer.h > +++ b/lib/librte_timer/rte_timer.h > @@ -275,7 +275,7 @@ int rte_timer_reset(struct rte_timer *tim, uint64_t > ticks, > * @param arg > * The user argument of the callback function. > */ > -void > +int > rte_timer_reset_sync(struct rte_timer *tim, uint64_t ticks, > enum rte_timer_type type, unsigned tim_lcore, > rte_timer_cb_t fct, void *arg); > @@ -314,7 +314,7 @@ int rte_timer_stop(struct rte_timer *tim); > * @param tim > * The timer handle. > */ > -void rte_timer_stop_sync(struct rte_timer *tim); > +int rte_timer_stop_sync(struct rte_timer *tim); >=20 > /** > * Test if a timer is pending. > -- > 2.17.1