[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |