Re: [Qemu-devel] [PATCH 1/2] virtio-9p: print error message and exit instead of BUG_ON()

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 08, 2016 at 11:12:16AM +0200, Greg Kurz wrote:
> On Thu, 8 Sep 2016 10:59:26 +0200
> Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> 
> > On Wed, 07 Sep 2016 19:19:24 +0200
> > Greg Kurz <groug@kaod.org> 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 <groug@kaod.org>
> > > ---
> > >  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.


> > The right way to go is to mark the virtio device as broken and stop
> > doing any processing until the guest resets it. I think Stefan had a
> > patch series doing that for some base virtio errors, but I'd have to
> > search for it.
> > 
> 
> I'd be glad to have a look and try to address this issue.
> 
> Thanks !
> 
> --
> Greg