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 BF147106B for ; Mon, 23 Mar 2015 16:36:34 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 23 Mar 2015 08:36:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,452,1422950400"; d="scan'208";a="684304350" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by fmsmga001.fm.intel.com with ESMTP; 23 Mar 2015 08:36:32 -0700 Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 23 Mar 2015 23:36:31 +0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 23 Mar 2015 23:36:31 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.36]) by shsmsx102.ccr.corp.intel.com ([169.254.2.198]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 23:36:30 +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:36:28 +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:36:35 -0000 On 3/23/2015 11:27 PM, Pavel Boldin wrote: On Mon, Mar 23, 2015 at 5:16 PM, Xie, Huawei > wrote: 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. The code of this module received little to none review and requires some lo= ve at the moment. I wanted to refactor the module completely but Thomas said it is not going = to go into the 2.0. So I decided to make a simple one-line fix. Another isse is do we really need a src fd here? Could we just allocate a u= nsed fd in the kernel and installed it with the target eventfd. If you are interested this [0] is the latest version of the refactoring pat= ch. I can provide you with an application that checks that there is indeed no l= eakage and ensures that the `eventfd' moving works. It is being used in our= builds as a test [1]. The code is "heredoc"ed in [2] [0] http://dpdk.org/dev/patchwork/patch/4113/ [1] https://review.fuel-infra.org/#/c/4639/ [2] https://review.fuel-infra.org/#/c/4639/3/tests/runtests.sh Pavel 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;