From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYlPc-0002h2-R8 for qemu-devel@nongnu.org; Sat, 13 Aug 2016 22:44:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYlPY-0001N5-M3 for qemu-devel@nongnu.org; Sat, 13 Aug 2016 22:44:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYlPY-0001Mu-F2 for qemu-devel@nongnu.org; Sat, 13 Aug 2016 22:44:28 -0400 Date: Sun, 14 Aug 2016 05:44:23 +0300 From: "Michael S. Tsirkin" Message-ID: <20160814054304-mutt-send-email-mst@kernel.org> References: <1470842980-32481-1-git-send-email-mst@redhat.com> <1470842980-32481-4-git-send-email-mst@redhat.com> <20160812063828.GG2759@al.usersys.redhat.com> <1956404709.2011431.1470986456062.JavaMail.zimbra@redhat.com> <20160812184549-mutt-send-email-mst@kernel.org> <2113870924.2312015.1471017294088.JavaMail.zimbra@redhat.com> <20160813001158-mutt-send-email-mst@kernel.org> <938177459.2407653.1471068826179.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <938177459.2407653.1471068826179.JavaMail.zimbra@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Cc: Prerna Saxena , Fam Zheng , qemu-devel@nongnu.org, Peter Maydell , marcandre lureau On Sat, Aug 13, 2016 at 02:13:46AM -0400, Marc-Andr=C3=A9 Lureau wrote: > Hi >=20 > ----- Original Message ----- > > On Fri, Aug 12, 2016 at 11:54:54AM -0400, Marc-Andr=C3=A9 Lureau wrot= e: > > > Hi > > >=20 > > > ----- Original Message ----- > > > > On Fri, Aug 12, 2016 at 03:20:56AM -0400, Marc-Andr=C3=A9 Lureau = wrote: > > > > > Hi > > > > >=20 > > > > > ----- Original Message ----- > > > > > > sent a follow-up response to GET_FEATURES), I am now wonderin= g if > > > > > > this > > > > > > patch > > > > > > may break existing vhost applications too ? If so, reverting = it > > > > > > possibly > > > > > > better. > > > > > > What confuses me is why it doesn=E2=80=99t fail all the time,= but only about > > > > > > 20% > > > > > > to > > > > > > 30% time as Fam reports. > > > > > >=20 > > > > > > Thoughts : Michael, Fam, MarcAndre ? > > > > >=20 > > > > > Indeed, I didn't ack that patch in the first place for that kin= d of > > > > > reasons, so I would revert it. > > > > >=20 > > > > > thanks > > > >=20 > > > > I guess that's the safest thing to do for 2.7. > > > > At least that's not any worse than 2.6. > > > > I still think it's a good idea long term and test should be fixed= , > > > > but let's revert for now. > > > >=20 > > >=20 > > > What about other backends that may have similar expectations from t= he > > > protocol. > > >=20 > > > This patch is a hack, there is no reason to have it upstream. > >=20 > > The reason is to avoid crashes with existing backends. >=20 > Which backend? I had a similar issue, it wasn't about crashes, and Prer= na didn't mention crashes either, but anyway there is not guarantee that = adding a GET_FEATURES message will solve it... >=20 So what bothers me the most about dropping this is that there are no backends with the new feature implemented at the moment. The GET_FEATURES hack at least makes it easy to test with existing backends ... > > > The solution is provided with the REPLY_ACK patch. > >=20 > > It needs a backend update though. > >=20 > > But the issue is old, it's not a regression. I think we lose nothing > > by pushing the work-around out until after 2.7. > >=20 > > -- > > MST > >=20