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

Re: [Xen-devel] [PATCH v3 21/28] tools/libxl: Infrastructure for writing a v2 stream



Andrew Cooper writes ("[PATCH v3 21/28] tools/libxl: Infrastructure for writing 
a v2 stream"):
...
> +void libxl__stream_write_start(libxl__egc *egc,
> +                               libxl__stream_write_state *stream)
> +{
> +    libxl__datacopier_state *dc = &stream->dc;
> +    STATE_AO_GC(stream->ao);
> +    struct libxl__sr_hdr hdr = { 0 };
...
> +    libxl__datacopier_prefixdata(egc, dc, &hdr, sizeof(hdr));

Sadly this pattern is not correct.  I don't think this initialisation
ensures that the memory in hdr is all-bits-0.  So you may leak
arbitrary data from the toolstack process stack into the migration or
save stream.

I think you need to use FILLZERO.

> +    struct libxl__sr_rec_hdr rec = { REC_TYPE_LIBXC_CONTEXT };
...
> +    setup_write(egc, stream, "libxc header",
> +                &rec, NULL, libxc_header_done);

Same again.

(I haven't searched thoroughly for these.)


> +/*----- Success/error/cleanup handling. -----*/

As with read, I would prefer these to be unified into one
stream_complete function.

> +    /* Don't fire the callback until all our parallel tasks have stopped. */
> +    if (!libxl__stream_write_inuse(stream) &&
> +        !libxl__save_helper_inuse(&dss->shs))
> +        stream->completion_callback(egc, stream, stream->rc);

My stylistic comment about the sense of the if applies here.  But as I
say it's a matter of taste.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.