From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id 1D38A1B342; Wed, 14 Feb 2018 08:52:43 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 92A7AEAEB1; Wed, 14 Feb 2018 07:52:42 +0000 (UTC) Received: from [10.36.112.38] (ovpn-112-38.ams2.redhat.com [10.36.112.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DD422113B71; Wed, 14 Feb 2018 07:52:39 +0000 (UTC) To: "Tan, Jianfeng" , dev@dpdk.org, yliu@fridaylinux.org, tiwei.bie@intel.com, vkaplans@redhat.com Cc: stable@dpdk.org, jfreiman@redhat.com References: <20171124180826.18439-1-maxime.coquelin@redhat.com> <20171124180826.18439-3-maxime.coquelin@redhat.com> <06080f95-a65a-a449-1c47-72b9d4d53122@redhat.com> <2bb2c3fa-597f-ad32-0b8e-0db6136d0a09@intel.com> From: Maxime Coquelin Message-ID: <4852f365-5c42-1f8e-3a48-467e2a3a2af8@redhat.com> Date: Wed, 14 Feb 2018 08:52:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <2bb2c3fa-597f-ad32-0b8e-0db6136d0a09@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 14 Feb 2018 07:52:42 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 14 Feb 2018 07:52:42 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'maxime.coquelin@redhat.com' RCPT:'' Subject: Re: [dpdk-dev] [PATCH v2 2/3] vhost: protect dirty logging against logging base change X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 07:52:43 -0000 Hi Jianfeng, On 02/14/2018 03:03 AM, Tan, Jianfeng wrote: > Hi Maxime, > > > On 11/28/2017 6:06 PM, Maxime Coquelin wrote: >> >> >> 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 >> Cannot access memory at address 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. > > I would assume this issue has been addressed by the per-queue lock patch > from Victor, correct? Correct. > Besides, we really don't need multiple unmap/map for each vq. Would you > think this shall be fixed in QEMU? Yes, I tihnk you are right it should be fixed in QEMU, so that it is sent only for the first queue pair. But I didn't had time to work on it TBH. Cheers, Maxime > Thanks, > Jianfeng