From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: [PATCH v3 4/5] eal: prevent secondary process init
 while sending messages
Date: Wed, 28 Feb 2018 10:19:45 +0000
Message-ID: <78e91c1c-2f7f-e93b-4e4b-ef1d77aa1140@intel.com>
References: <31f6d9ef676fb1eb0a664c06d62d66f32876dcb6.1519672713.git.anatoly.burakov@intel.com>
 <4be9dbc2f5751e9584f69997d4ef0077992eae52.1519740527.git.anatoly.burakov@intel.com>
 <ED26CBA2FAD1BF48A8719AEF02201E365145576A@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126])
 by dpdk.org (Postfix) with ESMTP id D2AF01D9E
 for <dev@dpdk.org>; Wed, 28 Feb 2018 11:19:47 +0100 (CET)
In-Reply-To: <ED26CBA2FAD1BF48A8719AEF02201E365145576A@SHSMSX103.ccr.corp.intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 28-Feb-18 1:58 AM, Tan, Jianfeng wrote:
> Hi Anatoly,
> 
>> -----Original Message-----
>> From: Burakov, Anatoly
>> Sent: Tuesday, February 27, 2018 10:36 PM
>> To: dev@dpdk.org
>> Cc: Tan, Jianfeng
>> Subject: [PATCH v3 4/5] eal: prevent secondary process init while sending
>> messages
>>
>> Currently, it is possible to spin up a secondary process while
>> either sendmsg or request is in progress. Fix this by adding
>> directory locks during init, sendmsg and requests.
> 
> Could you give a more detailed example for this issue?
> 
> And why locking the directory can help?
> 
> Thanks,
> Jianfeng
> 

Consider this. You start a request. Since sending this out takes 
non-zero amount of time, and you're waiting for process to reply each 
time you send a message, there's a non-zero chance where contents of 
/var/run may change and another socket file may appear that wasn't there 
when we started sending out those messages.

This is simply making sending requests atomic, if you will. Honestly, i 
can't think of a situation where this might be a problem, but it just 
doesn't feel right, so i fixed it :)

-- 
Thanks,
Anatoly