From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 6E344C422 for ; Tue, 30 Jun 2015 11:21:02 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 30 Jun 2015 02:21:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,376,1432623600"; d="scan'208";a="516477035" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by FMSMGA003.fm.intel.com with ESMTP; 30 Jun 2015 02:21:00 -0700 Received: from shecgisg003.sh.intel.com (shecgisg003.sh.intel.com [10.239.29.90]) by shvmail01.sh.intel.com with ESMTP id t5U9KvM1030304; Tue, 30 Jun 2015 17:20:57 +0800 Received: from shecgisg003.sh.intel.com (localhost [127.0.0.1]) by shecgisg003.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id t5U9KsNP003593; Tue, 30 Jun 2015 17:20:56 +0800 Received: (from hxie5@localhost) by shecgisg003.sh.intel.com (8.13.6/8.13.6/Submit) id t5U9KsOP003589; Tue, 30 Jun 2015 17:20:54 +0800 From: Huawei Xie To: dev@dpdk.org Date: Tue, 30 Jun 2015 17:20:47 +0800 Message-Id: <1435656050-3539-2-git-send-email-huawei.xie@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1435656050-3539-1-git-send-email-huawei.xie@intel.com> References: <1434649260-26317-2-git-send-email-huawei.xie@intel.com> <1435656050-3539-1-git-send-email-huawei.xie@intel.com> Subject: [dpdk-dev] [PATCH v4 1/4] vhost: call fdset_del_slot to remove connection fd 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, 30 Jun 2015 09:21:04 -0000 In the event handler of connection fd, the connection fd could be possibly closed. The event dispatch loop would then try to remove the fd from fdset. Between these two actions, another thread might register a new listenfd reusing the val of just closed fd, so we couldn't call fdset_del which would wrongly clean up the new listenfd. A new function fdset_del_slot is provided to cleanup the fd at the specified location. v4 changes: - call fdset_del_slot to remove connection fd Signed-off-by: Huawei Xie --- lib/librte_vhost/vhost_user/fd_man.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/lib/librte_vhost/vhost_user/fd_man.c b/lib/librte_vhost/vhost_user/fd_man.c index 831c9c1..bd30f8d 100644 --- a/lib/librte_vhost/vhost_user/fd_man.c +++ b/lib/librte_vhost/vhost_user/fd_man.c @@ -188,6 +188,24 @@ fdset_del(struct fdset *pfdset, int fd) } /** + * Unregister the fd at the specified slot from the fdset. + */ +static void +fdset_del_slot(struct fdset *pfdset, int index) +{ + if (pfdset == NULL || index < 0 || index >= MAX_FDS) + return; + + pthread_mutex_lock(&pfdset->fd_mutex); + + pfdset->fd[index].fd = -1; + pfdset->fd[index].rcb = pfdset->fd[index].wcb = NULL; + pfdset->num--; + + pthread_mutex_unlock(&pfdset->fd_mutex); +} + +/** * This functions runs in infinite blocking loop until there is no fd in * pfdset. It calls corresponding r/w handler if there is event on the fd. * @@ -248,8 +266,15 @@ fdset_event_dispatch(struct fdset *pfdset) * We don't allow fdset_del to be called in callback * directly. */ + /* + * When we are to clean up the fd from fdset, + * because the fd is closed in the cb, + * the old fd val could be reused by when creates new + * listen fd in another thread, we couldn't call + * fd_set_del. + */ if (remove1 || remove2) - fdset_del(pfdset, fd); + fdset_del_slot(pfdset, i); } } } -- 1.8.1.4