From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Coquelin Subject: Re: [PATCH v2 2/3] vhost: protect dirty logging against logging base change Date: Tue, 28 Nov 2017 11:06:15 +0100 Message-ID: <06080f95-a65a-a449-1c47-72b9d4d53122@redhat.com> References: <20171124180826.18439-1-maxime.coquelin@redhat.com> <20171124180826.18439-3-maxime.coquelin@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@dpdk.org, jfreiman@redhat.com To: dev@dpdk.org, yliu@fridaylinux.org, tiwei.bie@intel.com, jianfeng.tan@intel.com, vkaplans@redhat.com Return-path: In-Reply-To: <20171124180826.18439-3-maxime.coquelin@redhat.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 11/24/2017 07:08 PM, Maxime Coquelin wrote: > When performing live-migration with multiple queue pairs, > VHOST_USER_SET_LOG_BASE request is sent multiple times. > > If packets are being processed by the PMD threads, it is > possible that they are setting bits in the dirty log map while > its region is being unmapped by the vhost-user protocol thread. > It results in the following crash: > Thread 3 "lcore-slave-2" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7f71ca495700 (LWP 32451)] > 0x00000000004bfc8a in vhost_set_bit (addr=0x7f71cbe18432 , nr=1) at /home/max/projects/src/mainline/dpdk/lib/librte_vhost/vhost.h:267 > 267 __sync_fetch_and_or_8(addr, (1U << nr)); > > We can see the vhost-user protocol thread just did the unmap of the > dirty log region when it happens. > > This patch prevents this by introducing a RW lock to protect > the log base. > > Fixes: 54f9e32305d4 ("vhost: handle dirty pages logging request") > Cc: stable@dpdk.org > > Signed-off-by: Maxime Coquelin > --- > lib/librte_vhost/vhost.c | 2 ++ > lib/librte_vhost/vhost.h | 14 +++++++++++--- > lib/librte_vhost/vhost_user.c | 4 ++++ > 3 files changed, 17 insertions(+), 3 deletions(-) > By clarifying the vhost-user spec, we may be able to avoid this lock and just ignore the subsequent SET_LOG_BASE requests once VHOST_F_LOG_ALL feature bit is set. So let's just discard this series for now. Maxime