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 C4CB495D9 for ; Sat, 6 Feb 2016 06:21:09 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 05 Feb 2016 21:21:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,404,1449561600"; d="scan'208";a="648047165" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 05 Feb 2016 21:21:08 -0800 Date: Sat, 6 Feb 2016 13:23:20 +0800 From: Yuanhan Liu To: Rich Lane Message-ID: <20160206052320.GJ22958@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 06 Feb 2016 05:21:11 -0000 Hey Rich, Sorry for the long delay; I barely forgot it :( On Tue, Jan 19, 2016 at 10:13:23AM -0800, Rich Lane wrote: > 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: > > +/* > > + * 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. "backend" is just a more common word to me, as well as to QEMU. So, I would suggest you to do such change, and if so, you could add my ACK: Acked-by: Yuanhan Liu > > 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(). Well, you could: case VHOST_USER_RESET_OWNER: ops->reset_owner(); vhost_user_unmap(); break; Anyway, it's not a big deal. Let's go with your solution first. --yliu > 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.