All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/9] block: vhdx - add header update capability.
Date: Thu, 1 Aug 2013 15:44:41 +0200	[thread overview]
Message-ID: <20130801134441.GD2387@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <595d71cf1cd25ac9deff521bceb82b8c3da888d0.1375325971.git.jcody@redhat.com>

On Wed, Jul 31, 2013 at 11:23:47PM -0400, Jeff Cody wrote:
> @@ -212,6 +242,24 @@ bool vhdx_checksum_is_valid(uint8_t *buf, size_t size, int crc_offset)
>  
>  
>  /*
> + * This generates a UUID that is compliant with the MS GUIDs used
> + * in the VHDX spec (and elsewhere).
> + *
> + * We can do this with uuid_generate if uuid.h is present,
> + * however not all systems have uuid and the generation is
> + * pretty straightforward for the DCE + random usage case

The talk of uuid.h not being available confuses me.  The code has no
#ifdef and we do not define uuid_generate() ourselves.

Is this an outdated comment?

> +/* Update the VHDX headers
> + *
> + * This follows the VHDX spec procedures for header updates.
> + *
> + *  - non-current header is updated with largest sequence number
> + */
> +static int vhdx_update_header(BlockDriverState *bs, BDRVVHDXState *s, bool rw)

"rw" should be named "generate_file_write_guid".  If you call
vhdx_update_header() again later you do not need to update FileWriteGuid
again according to the spec.  There's probably no harm in doing so but
the spec explicitly says "If this is the first header update within the
session, use a new value for the FileWriteGuid".

This means that future calls to vhdx_update_header() in the same session
should set "generate_file_write_guid" to false.  Therefore "rw" is not
the right name.

> +{
> +    int ret = 0;
> +    int hdr_idx = 0;
> +    uint64_t header_offset = VHDX_HEADER1_OFFSET;
> +
> +    VHDXHeader *active_header;
> +    VHDXHeader *inactive_header;
> +    VHDXHeader header_le;
> +    uint8_t *buffer;
> +
> +    /* operate on the non-current header */
> +    if (s->curr_header == 0) {
> +        hdr_idx = 1;
> +        header_offset = VHDX_HEADER2_OFFSET;
> +    }
> +
> +    active_header   = s->headers[s->curr_header];
> +    inactive_header = s->headers[hdr_idx];
> +
> +    inactive_header->sequence_number = active_header->sequence_number + 1;
> +
> +    /* a new file guid must be generate before any file write, including

s/generate/generated/

> +     * headers */
> +    memcpy(&inactive_header->file_write_guid, &s->session_guid,
> +           sizeof(MSGUID));
> +
> +    /* a new data guid only needs to be generate before any guest-visible
> +     * writes, so update it if the image is opened r/w. */
> +    if (rw) {
> +        vhdx_guid_generate(&inactive_header->data_write_guid);
> +    }
> +
> +    /* the header checksum is not over just the packed size of VHDXHeader,
> +     * but rather over the entire 'reserved' range for the header, which is
> +     * 4KB (VHDX_HEADER_SIZE). */
> +
> +    buffer = qemu_blockalign(bs, VHDX_HEADER_SIZE);
> +    /* we can't assume the extra reserved bytes are 0 */
> +    ret = bdrv_pread(bs->file, header_offset, buffer, VHDX_HEADER_SIZE);
> +    if (ret < 0) {
> +        goto exit;
> +    }
> +    /* overwrite the actual VHDXHeader portion */
> +    memcpy(buffer, inactive_header, sizeof(VHDXHeader));
> +    inactive_header->checksum = vhdx_update_checksum(buffer,
> +                                                     VHDX_HEADER_SIZE, 4);
> +    vhdx_header_le_export(inactive_header, &header_le);
> +    bdrv_pwrite_sync(bs->file, header_offset, &header_le, sizeof(VHDXHeader));

This function can fail and it's a good indicator that future I/Os will
also be in trouble.  Please propagate the error return.

> @@ -801,8 +955,7 @@ static int vhdx_open(BlockDriverState *bs, QDict *options, int flags)
>      }
>  
>      if (flags & BDRV_O_RDWR) {
> -        ret = -ENOTSUP;
> -        goto fail;
> +        vhdx_update_headers(bs, s, false);

Error handling is missing.  At this point it looks like we cannot write
to the file.  Propagating the error seems reasonable.

  reply	other threads:[~2013-08-01 18:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01  3:23 [Qemu-devel] [PATCH v2 0/9] VHDX log replay and write support Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 1/9] block: vhdx - minor comments and typo correction Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 2/9] block: vhdx - add header update capability Jeff Cody
2013-08-01 13:44   ` Stefan Hajnoczi [this message]
2013-08-01 14:09     ` Jeff Cody
2013-08-07 14:42     ` Jeff Cody
2013-08-05 11:42   ` Kevin Wolf
2013-08-05 14:43     ` Jeff Cody
2013-08-05 14:45   ` Kevin Wolf
2013-08-05 14:57     ` Jeff Cody
2013-08-05 15:05   ` Kevin Wolf
2013-08-05 15:09     ` Jeff Cody
2013-08-06  8:34       ` Kevin Wolf
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 3/9] block: vhdx code movement - VHDXMetadataEntries and BDRVVHDXState to header Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 4/9] block: vhdx - log support struct and defines Jeff Cody
2013-08-01 15:00   ` Stefan Hajnoczi
2013-08-01 15:51     ` Jeff Cody
2013-08-07 15:22   ` Kevin Wolf
2013-08-07 17:18     ` Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 5/9] block: vhdx - break endian translation functions out Jeff Cody
2013-08-01 15:03   ` Stefan Hajnoczi
2013-08-01 15:14     ` Jeff Cody
2013-08-07 15:29   ` Kevin Wolf
2013-08-07 17:21     ` Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 6/9] block: vhdx - update log guid in header, and first write tracker Jeff Cody
2013-08-01 15:09   ` Stefan Hajnoczi
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 7/9] block: vhdx - log parsing, replay, and flush support Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 8/9] block: vhdx - add log write support Jeff Cody
2013-08-01  3:23 ` [Qemu-devel] [PATCH v2 9/9] block: vhdx " Jeff Cody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130801134441.GD2387@stefanha-thinkpad.redhat.com \
    --to=stefanha@redhat.com \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.