[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
pgp_vN2OoAqT7.pgp
Description: PGP signature