From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bi2bk-0003AV-Ex for qemu-devel@nongnu.org; Thu, 08 Sep 2016 12:55:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bi2be-0004qU-MV for qemu-devel@nongnu.org; Thu, 08 Sep 2016 12:55:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bi2be-0004qB-FQ for qemu-devel@nongnu.org; Thu, 08 Sep 2016 12:55:18 -0400 Date: Thu, 8 Sep 2016 19:55:16 +0300 From: "Michael S. Tsirkin" Message-ID: <20160908194939-mutt-send-email-mst@kernel.org> References: <147326875705.8546.11347276277137015855.stgit@bahia.lan> <147326876478.8546.16045138068342092499.stgit@bahia.lan> <20160908105926.0d968e64.cornelia.huck@de.ibm.com> <20160908111216.12a1b562@bahia> <20160908175237-mutt-send-email-mst@kernel.org> <20160908170447.2d864945.cornelia.huck@de.ibm.com> <20160908181732-mutt-send-email-mst@kernel.org> <20160908182652.2cf51ac0@bahia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160908182652.2cf51ac0@bahia> Subject: Re: [Qemu-devel] [PATCH 1/2] virtio-9p: print error message and exit instead of BUG_ON() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Cornelia Huck , qemu-devel@nongnu.org, "Aneesh Kumar K.V" On Thu, Sep 08, 2016 at 06:26:52PM +0200, Greg Kurz wrote: > On Thu, 8 Sep 2016 18:19:27 +0300 > "Michael S. Tsirkin" wrote: > > > On Thu, Sep 08, 2016 at 05:04:47PM +0200, Cornelia Huck wrote: > > > On Thu, 8 Sep 2016 18:00:28 +0300 > > > "Michael S. Tsirkin" wrote: > > > > > > > On Thu, Sep 08, 2016 at 11:12:16AM +0200, Greg Kurz wrote: > > > > > On Thu, 8 Sep 2016 10:59:26 +0200 > > > > > Cornelia Huck wrote: > > > > > > > > > > > On Wed, 07 Sep 2016 19:19:24 +0200 > > > > > > Greg Kurz wrote: > > > > > > > > > > > > > Calling assert() really makes sense when hitting a genuine bug, which calls > > > > > > > for a fix in QEMU. However, when something goes wrong because the guest > > > > > > > sends a malformed message, it is better to write down a more meaningul > > > > > > > error message and exit. > > > > > > > > > > > > > > Signed-off-by: Greg Kurz > > > > > > > --- > > > > > > > hw/9pfs/virtio-9p-device.c | 20 ++++++++++++++++++-- > > > > > > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > > > > > > > > > While this is an improvement over the current state, I don't think the > > > > > > guest should be able to kill qemu just by doing something stupid. > > > > > > > > > > > > > > > > Hi Connie, > > > > > > > > > > I'm glad you're pointing this out... this was also my impression, but > > > > > since there are a bunch of sanity checks in the virtio code that cause > > > > > QEMU to exit (even recently added like 1e7aed70144b), I did not dare > > > > > stand up :) > > > > > > > > It's true that it's broken in many places but we should just > > > > fix them all. > > > > > > > > > > > > A separate question is how to log such hardware/guest bugs generally. > > > > People already complained about disk filling up because of us printing > > > > errors on each such bug. Maybe print each message only N times, and > > > > then set a flag to skip the log until management tells us to restart > > > > logging again. > > > > > > I'd expect to get the message just once per device if we set the device > > > to broken (unless the guess continuously resets it again...) > > > > Which it can do, so we should limit that anyway. > > > > > Do we have > > > a generic print/log ratelimit infrastructure in qemu? > > > > There are actually two kinds of errors > > host side ones and ones triggered by guests. > > > > We should distinguish between them API-wise, then > > we will be able to limit the logging of those > > that guest can trigger. > > > > FWIW it makes sense to use error_report() if QEMU exits. Not necessarily e.g. hotplug errors trigger error_report too. Generally it should be for host misconfiguration or similar management errors. > If it continues > execution, this means we're expecting the guest or the host to do something > to fix the error condition. This requires QEMU to emit an event of some > sort, but not necessarily to log an error message in a file. I guess this > depends if QEMU is run by some tooling, or by a human. I'm not sure we need an event if tools are not expected to do anything with it. If we limit # of times error is printed, tools will need to reset this counter, so we will need an event on overflow. -- MST