From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com [209.85.213.41]) by dpdk.org (Postfix) with ESMTP id 2F9875A32 for ; Tue, 19 Jan 2016 19:13:24 +0100 (CET) Received: by mail-vk0-f41.google.com with SMTP id k1so353008838vkb.2 for ; Tue, 19 Jan 2016 10:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bigswitch-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6pXrc+NYHiAr6Sq8tx0U8HQTGGbTtf/iypeeTw+Q8Q8=; b=rFpm20zjJTWLUrOuAN36JSmi1RGWARiVN87rAoNhEqzycGcQD+XQs0QE6pCIx1ISFe ZZ+Zc3NDMBvweeFGEHU/IB7kQVE8G0GJTx4JbhzYDWGbKHjAFmI+WCWLanX7ac6MWkkz REjZ9K2xFPI9oHNAPem1AlHeyJFJud1blZh359s9ZSIQZq79LA1HxXFxgBaWW+1eG5kO EDaHP94rYRoyfEYECXjnkciM1sBjkRfiRl1SC+EJAGJD6RWfYbLbMOem0lDXoYvYev9z 4hYpUMxtxF4gr0Ow4ejPsBGRt6kOyjhIYnji+YQPXuwdm7vkCmL6K2DBvjt8VZPp7rJQ XJZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6pXrc+NYHiAr6Sq8tx0U8HQTGGbTtf/iypeeTw+Q8Q8=; b=MUjCeG+qTiBQJb4HNedNKmBymkZvmQIQcdoXmKc7Z1N5HxFhriynh2LQVT1ftNWeYN xwOJ62YBAPRm4g0IJgwXDd3hbtvotCnHgTS1S6kiCNmGMFUfKoVrCHm3ea5mMJ2DZM85 5Z0oxTDWqbk6Sy59GsqBpGbD2b38Ds+/Axk31pl6WnwFG39oOrU+LXlDSWisiTt6XLPs MdHvvMiCo+cSkfnTrapbPYRZ9llXHk7PgXgDvJJD/VC7m2ZLw6moQwi4OQXr53GwKO3f Jm9tPXzB7CuScZ808gvxRPIel0W5ULiolB56Tf39pSA1UJuWSNGJBbAaxwljxT04NeU4 Sm3g== X-Gm-Message-State: AG10YOTuy3qWlJhx2dqXxmkKSaDasWvjHmDP8eTczAWBTErYmep2GKk3WF/Afg18AarfqJqZqbd0qLwpaxCYe96r MIME-Version: 1.0 X-Received: by 10.31.54.80 with SMTP id d77mr13999064vka.138.1453227203605; Tue, 19 Jan 2016 10:13:23 -0800 (PST) Received: by 10.31.129.9 with HTTP; Tue, 19 Jan 2016 10:13:23 -0800 (PST) In-Reply-To: <20160118075808.GZ19531@yliu-dev.sh.intel.com> References: <1452032049-94324-1-git-send-email-rlane@bigswitch.com> <1453060638-58510-1-git-send-email-rlane@bigswitch.com> <20160118075808.GZ19531@yliu-dev.sh.intel.com> Date: Tue, 19 Jan 2016 10:13:23 -0800 Message-ID: From: Rich Lane To: Yuanhan Liu Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 1/1] vhost: fix leak of fds and mmaps 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: Tue, 19 Jan 2016 18:13:24 -0000 On Sun, Jan 17, 2016 at 11:58 PM, Yuanhan Liu wrote: > On Sun, Jan 17, 2016 at 11:57:18AM -0800, Rich Lane wrote: > > The common vhost code only supported a single mmap per device. vhost-user > > worked around this by saving the address/length/fd of each mmap after > the end > > of the rte_virtio_memory struct. This only works if the vhost-user code > frees > > dev->mem, since the common code is unaware of the extra info. The > > VHOST_USER_RESET_OWNER message is one situation where the common code > frees > > dev->mem and leaks the fds and mappings. This happens every time I shut > down a > > VM. > > > > The new code calls back into the implementation (vhost-user or > vhost-cuse) to > > clean up these resources. > > > > The vhost-cuse changes are only compile tested. > > > > Signed-off-by: Rich Lane > > --- > > v1->v2: > > - Call into vhost-user/vhost-cuse to free mmaps. > > > > lib/librte_vhost/vhost-net.h | 6 ++++++ > > lib/librte_vhost/vhost_cuse/virtio-net-cdev.c | 12 ++++++++++++ > > lib/librte_vhost/vhost_user/vhost-net-user.c | 1 - > > lib/librte_vhost/vhost_user/virtio-net-user.c | 25 > ++++++++++--------------- > > lib/librte_vhost/vhost_user/virtio-net-user.h | 1 - > > lib/librte_vhost/virtio-net.c | 8 +------- > > 6 files changed, 29 insertions(+), 24 deletions(-) > > > > diff --git a/lib/librte_vhost/vhost-net.h b/lib/librte_vhost/vhost-net.h > > index c69b60b..e8d7477 100644 > > --- a/lib/librte_vhost/vhost-net.h > > +++ b/lib/librte_vhost/vhost-net.h > > @@ -115,4 +115,10 @@ struct vhost_net_device_ops { > > > > > > struct vhost_net_device_ops const *get_virtio_net_callbacks(void); > > + > > +/* > > + * Implementation-specific cleanup. Defined by vhost-cuse and > vhost-user. > > + */ > > +void vhost_impl_cleanup(struct virtio_net *dev); > > TBH, I am not quite like "_impl_"; maybe "_backend_" is better? > If you have a strong preference I will change it. Let me know. > OTOH, what I thought of has slight difference than yours: not > necessary to export a function, but instead, call the vhost > backend specific unmap function inside the backend itself. Say, > call vhost_user_unmap() on RESET_OWNER and connection close. > What do you think of that? The munmap must be done after the notify_ops->destroy_device callback. That means the backend can't call it before reset_owner() or destroy_device(). The munmap could be done afterwards, but that requires saving dev->mem in the caller in the case of destroy_device. The cleanest solution is for the vhost common code to ask the backend to clean up at the correct time.