From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <huawei.xie@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id 01650C36E
 for <dev@dpdk.org>; Fri, 10 Jul 2015 17:32:47 +0200 (CEST)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by fmsmga103.fm.intel.com with ESMTP; 10 Jul 2015 08:32:47 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="603771787"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
 by orsmga003.jf.intel.com with ESMTP; 10 Jul 2015 08:32:45 -0700
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
 PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS)
 id 14.3.224.2; Fri, 10 Jul 2015 23:32:44 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.246]) by
 SHSMSX103.ccr.corp.intel.com ([169.254.4.46]) with mapi id 14.03.0224.002;
 Fri, 10 Jul 2015 23:32:37 +0800
From: "Xie, Huawei" <huawei.xie@intel.com>
To: Pavel Boldin <pboldin@mirantis.com>
Thread-Topic: [dpdk-dev] [PATCH v5 4/5] vhost: eventfd_link: replace
 copy-pasted sys_close
Thread-Index: AdC7JaWGV8dlCf+ynE6WaHWpLcGybQ==
Date: Fri, 10 Jul 2015 15:32:36 +0000
Message-ID: <C37D651A908B024F974696C65296B57B0F56C68F@SHSMSX101.ccr.corp.intel.com>
References: <1427994080-10163-1-git-send-email-pboldin@mirantis.com>
 <1429184910-30186-5-git-send-email-pboldin@mirantis.com>
 <C37D651A908B024F974696C65296B57B0F476567@SHSMSX101.ccr.corp.intel.com>
 <1665929.SfCu3BinAE@xps13>
 <C37D651A908B024F974696C65296B57B0F56C326@SHSMSX101.ccr.corp.intel.com>
 <CACf4_B_2M-Nc76kTDwxySgjS3LzYgJVLFz0GgNcWEpz-96WipQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v5 4/5] vhost: eventfd_link: replace
 copy-pasted sys_close
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2015 15:32:48 -0000

On 7/10/2015 10:50 PM, Pavel Boldin wrote:
Xie,

Regarding the patches:
1. The replaced code in fourth patch is checked to be a copy-paste of the `=
sys_close` syscall.
sys_close does extra cleanup than the replaced code. My concern is, for exa=
mple, sys_close will mark the fd as next-to-be-allocated fd. Will there be =
issue when we allocate a new fd? Because it will be allocated starting from=
 the next-to-be-allocated-fd. I think Kernel will do some check on that val=
ue, but not sure.

2. It is not uncommon for the applications to close FD making it allocated =
for a different file. In our particular case the file is closed in the *sou=
rce* process and *added* to a target process, so matching fds should not be=
 the problem.
Sure, that is what the old code does.
3. There is an implementation of the exact same thing in the SCM_RIGHTS [1]=
 that can be used as the reference code.
I did a rough check. Maybe i miss something. I see it calls fd_install on a=
 newly allocated fd. That is exactly what i think is the clean fix.
Currently we allocate eventfd in user space, and install a new file onto it=
. Actually  we don't need to allocate eventfd in user space at all, what we=
 should do is allocate a new fd, and install the file on the newly allocate=
d fd.

new_fd =3D get_unused_fd_flags(...)
fd_install(new_fd, get_file(fp[i]));

/huawei


[1] https://github.com/torvalds/linux/blob/master/net/core/scm.c#L248

Pavel

On Fri, Jul 10, 2015 at 5:27 PM, Xie, Huawei <huawei.xie@intel.com<mailto:h=
uawei.xie@intel.com>> wrote:
On 6/17/2015 11:24 PM, Thomas Monjalon wrote:
> 2015-05-07 06:54, Xie, Huawei:
>> On 4/16/2015 7:48 PM, Pavel Boldin wrote:
>>> +   /* Closing the source_fd */
>>> +   ret =3D sys_close(eventfd_copy.source_fd);
>> Pavel:
>> Here we close the fd and re-install a new file on this fd later.
>> sys_close does all cleanup.
>> But, for instance, if we allocate new fd later, normally it will reuse
>> the just freed fds by sys_close, is there issue here?
> Pavel, Huawei,
> Could we come to a conclusion on this patch series please?
For the previous 3 patches, i am OK except that i don't think inline is
needed explicitly for non-performance critical function.
For this patch, didn't check the fs code.

>
>