From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 50D03B62 for ; Mon, 23 Mar 2015 16:16:51 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 23 Mar 2015 08:16:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,452,1422950400"; d="scan'208";a="696397338" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by fmsmga002.fm.intel.com with ESMTP; 23 Mar 2015 08:16:49 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 23 Mar 2015 23:16:48 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.36]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.108]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 23:16:40 +0800 From: "Xie, Huawei" To: Pavel Boldin Thread-Topic: [dpdk-dev] [PATCH] vhost: Fix `struct file' leakage in `eventfd_link' Thread-Index: AQHQZXdtPUQpud64G0WGpf15n24cqw== Date: Mon, 23 Mar 2015 15:16:40 +0000 Message-ID: References: <1427115225-14489-1-git-send-email-pboldin@mirantis.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" Subject: Re: [dpdk-dev] [PATCH] vhost: Fix `struct file' leakage in `eventfd_link' 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: Mon, 23 Mar 2015 15:16:51 -0000 On 3/23/2015 10:52 PM, Pavel Boldin wrote: On Mon, Mar 23, 2015 at 4:41 PM, Xie, Huawei > wrote: On 3/23/2015 10:37 PM, Pavel Boldin wrote: On Mon, Mar 23, 2015 at 4:21 PM, Xie, Huawei >> wrote: On 3/23/2015 8:54 PM, Pavel Boldin wrote: > Due to increased `struct file's reference counter subsequent call > to `filp_close' does not free the `struct file'. Prepend `fput' call > to decrease the reference counter. > > Signed-off-by: Pavel Boldin >> > --- > lib/librte_vhost/eventfd_link/eventfd_link.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.c b/lib/librte_vh= ost/eventfd_link/eventfd_link.c > index 7755dd6..62c45c8 100644 > --- a/lib/librte_vhost/eventfd_link/eventfd_link.c > +++ b/lib/librte_vhost/eventfd_link/eventfd_link.c > @@ -117,6 +117,7 @@ eventfd_link_ioctl(struct file *f, unsigned int ioctl= , unsigned long arg) > * Release the existing eventfd in the source process > */ > spin_lock(&files->file_lock); > + fput(file); Could we just call atomic_long_dec here? We can but I don't like breaking encapsulation (which is broken anyway by t= he code). So, there is a special method and we should use it in my opinion. it is increased by atomic_long_inc_not_zero so why don't we use the symmetr= ic function? The code with `atomic_long_inc_not_zero' call is a copy-paste of the `fget'= function. If we want to make it clear we should make a separate function a= nd name it so: `fget_from_files'. I don't understand why there is a (exact?) copy&paste of fget there. :). Maybe you could post a patchset, first replace the copy/paste with fget and= then this patch. It will looks much clearer. Second thing is: another thread of the same processor can call the `sys_clo= se' on the `fd' and this will dereference counter so `fput' will correctly = free the `struct file'. Using `atomic_long_dec' will leak a `struct file' a= nd print a KERN_ERR message by `filp_close'. So, the common thing is to use appropriate functions and don't reinvent the= wheel. Pavel Pavel > filp_close(file, files); > fdt =3D files_fdtable(files); > fdt->fd[eventfd_copy.source_fd] =3D NULL;