qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/4] raw: Prohibit dangerous writes for probed i


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 3/4] raw: Prohibit dangerous writes for probed images
Date: Fri, 31 Oct 2014 10:34:42 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 30.10.2014 um 15:27 hat Eric Blake geschrieben:
> On 10/30/2014 06:26 AM, Kevin Wolf wrote:
> > 
> > The other differences of this patch to the old one are that it doesn't
> > silently write something different than the guest requested by zeroing
> > out some bytes (it fails the request instead) and that it doesn't
> > maintain a list of signatures in the raw driver (it calls the usual
> > probe function instead).
> > 
> > Signed-off-by: Kevin Wolf <address@hidden>
> > ---
> >  block.c                   |  5 +++--
> 
> > +
> > +        drv = bdrv_probe_all(buf, 512, NULL);
> > +        if (drv != bs->drv) {
> > +            ret = -EPERM;
> > +            goto fail;
> > +        }
> 
> So, what happens when this returns -EPERM?  If the guest is configured
> to halt on write errors, does this halt the guest and send an event to
> management?  How does it compare to the case of halting on ENOSPACE?  Is
> this particular failure mode something that the host should be able to
> easily distinguish from other failure modes?

This -EPERM is returned the same way as error that come directly from
the kernel, so the usual werror/rerror rules apply. It can easily be
distinguished from ENOSPC (nospace=false in the QMP event,
io-status=failed in BlockInfo for query-block), but it looks the same as
a regular I/O error.

> But I definitely like that you only do this failure on probed images,
> and that a user that requests an explicit raw format will never trip up.

Right, a management tool should always be passing the format explicitly
and shouldn't need to deal with this error case at all.

Kevin

Attachment: pgp_vN2OoAqT7.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]