On 05/07/2021 16:13, Jan Beulich wrote: > In send_memory_live() the precise value the dirty_count struct field > gets initialized to doesn't matter much (apart from the triggering of > the log message in send_dirty_pages(), see below), but it is important > that it not be zero on the first iteration (or else send_dirty_pages() > won't get called at all). Saturate the initializer value at the maximum > value the field can hold.
I've already explained why this is broken... > While there also initialize struct precopy_stats' respective field to a > more sane value: We don't really know how many dirty pages there are at > that point. > > In suspend_and_send_dirty() and verify_frames() the local variables > don't need initializing at all, as they're only an output from the > hypercall which gets invoked first thing. > > In send_checkpoint_dirty_pfn_list() the local variable can be dropped > altogether: It's optional to xc_logdirty_control() and not used anywhere > else. ... and why this is broken particularly in the context of a later change, and ... > > Note that in case the clipping actually takes effect, the "Bitmap > contained more entries than expected..." log message will trigger. This > being just an informational message, I don't think this is overly > concerning. ... why this isn't ok. Why do I bother wasting my time reviewing patches in the first place. ~Andrew
