From: Rich Lane <rich.lane@bigswitch.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 1/1] vhost: fix leak of fds and mmaps
Date: Tue, 19 Jan 2016 10:13:23 -0800 [thread overview]
Message-ID: <CAGSMBPN=5qemS6Ah4x5jUeqcULVWCaStOXp+0OA0mcBKGEHqEg@mail.gmail.com> (raw)
In-Reply-To: <20160118075808.GZ19531@yliu-dev.sh.intel.com>
On Sun, Jan 17, 2016 at 11:58 PM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
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 <rlane@bigswitch.com>
> > ---
> > 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.
next prev parent reply other threads:[~2016-01-19 18:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 22:14 [dpdk-dev] [PATCH] " Rich Lane
2016-01-07 2:31 ` Yuanhan Liu
2016-01-07 6:50 ` Xie, Huawei
2016-01-17 19:57 ` [dpdk-dev] [PATCH v2 1/1] " Rich Lane
2016-01-18 7:58 ` Yuanhan Liu
2016-01-19 18:13 ` Rich Lane [this message]
2016-02-06 5:23 ` Yuanhan Liu
2016-02-10 18:40 ` [dpdk-dev] [PATCH v3] " Rich Lane
2016-02-19 15:08 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGSMBPN=5qemS6Ah4x5jUeqcULVWCaStOXp+0OA0mcBKGEHqEg@mail.gmail.com' \
--to=rich.lane@bigswitch.com \
--cc=dev@dpdk.org \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).