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

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

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 <kwolf@redhat.com>
> > ---
> >  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 #2: Type: application/pgp-signature, Size: 836 bytes --]