From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 592AA7DF7 for ; Fri, 26 Sep 2014 20:01:09 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 26 Sep 2014 11:07:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,604,1406617200"; d="scan'208";a="605960288" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga002.fm.intel.com with ESMTP; 26 Sep 2014 11:07:16 -0700 Received: from irsmsx153.ger.corp.intel.com (163.33.192.75) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 19:07:15 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.248]) by IRSMSX153.ger.corp.intel.com ([169.254.9.42]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 19:07:15 +0100 From: "Ananyev, Konstantin" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: Thread-Index: AQHP2MAqmY9s5RkexE+yRGxj2kXnOpwR4sKAgAAemtCAAAdaAIAAZ8zwgADMQACAAA5cAIAAEWsAgAAnzM6AAAITkIAAAzQAgAApX+A= Date: Fri, 26 Sep 2014 18:07:14 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772582137D95F@IRSMSX104.ger.corp.intel.com> References: <20140925150807.GD32725@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB977258213769DE@IRSMSX105.ger.corp.intel.com> <20140925172358.GG32725@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB97725821378B50@IRSMSX104.ger.corp.intel.com> <20140926114630.GA3930@hmsreliant.think-freely.org> <20140926134014.GB3930@hmsreliant.think-freely.org> <20140926150156.GB5619@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB9772582137D88E@IRSMSX104.ger.corp.intel.com> <20140926162134.GE5619@hmsreliant.think-freely.org> In-Reply-To: <20140926162134.GE5619@hmsreliant.think-freely.org> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 18:01:09 -0000 > > As I remember the purpose of the patch was to fix the race condition in= side rte_alarm library. > > I believe that the patch provided by Michal & Pawel fixes the issues yo= u discovered. > > If you think, that is not the case, could you please provide a list of = remaining issues? > > Excluding ones that you just don't like it, and you are not happy with = rte_alarm API in total? > Gladly. As Pawel explained the race, its possible that, after calling > rte_eal_alarm_cancel, an in-flight execution of an alarm callback may sti= ll be > running. The problem with that ostensibly is that data which is being ac= cessed > by the callback might be then accessed in parallel with another process l= eading > to data corruption or some other problem. The issue I have with his patch= is > that it doesn't completely close the race. While it does close the race = for the > condition in whcih thread B is running the alarm callback while thread A = is > executing the cancel operation, it does not close the case for when a sin= gle > thread B is running the cancel operation, as the in-flight execution itse= lf is > still active. A bit puzzled here: Are you saying that calling alarm_cancel() for itself inside eal_alarm_call= back() might cause a problem? I still don't see how. > If such a cancellation occurs via an intermediary function (i.e. > one which is not aware that it is explicitly running an alarm callback, w= hich > signals another thread to execute via some other method (ipc communicatio= n, > etc), the same data corruption may occur, because the canceled and comple= te > guarantee has been violated. >=20