From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYEnY-0004Hp-68 for qemu-devel@nongnu.org; Fri, 12 Aug 2016 11:55:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYEnS-00050u-Ag for qemu-devel@nongnu.org; Fri, 12 Aug 2016 11:55:03 -0400 Received: from mx5-phx2.redhat.com ([209.132.183.37]:56711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYEnS-00050c-2Y for qemu-devel@nongnu.org; Fri, 12 Aug 2016 11:54:58 -0400 Date: Fri, 12 Aug 2016 11:54:54 -0400 (EDT) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <2113870924.2312015.1471017294088.JavaMail.zimbra@redhat.com> In-Reply-To: <20160812184549-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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: "Michael S. Tsirkin" Cc: Prerna Saxena , Fam Zheng , qemu-devel@nongnu.org, Peter Maydell , marcandre lureau Hi ----- 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 wondering if thi= s > > > patch > > > may break existing vhost applications too ? If so, reverting it possi= bly > > > better. > > > What confuses me is why it doesn=E2=80=99t fail all the time, but onl= y 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 kind 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 What about other backends that may have similar expectations from the proto= col. This patch is a hack, there is no reason to have it upstream. The solution = is provided with the REPLY_ACK patch.