Re: [PATCH 06/12] libxenguest: guard against overflow from too large p2m when checkpointing

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.06.2021 21:00, Andrew Cooper wrote:
> On 25/06/2021 14:20, Jan Beulich wrote:
>> struct xc_sr_record's length field has just 32 bits.
> 
> The stream max record length is
> 
> /* Somewhat arbitrary - 128MB */
> #define REC_LENGTH_MAX                (128U << 20)
> 
> and is checked in the low level helpers, making the upper bound on the
> number of PFNs 0xFFFFFF once the record header is taken into account.
> 
> There doesn't appear to have been any consideration made to what happens
> if this number gets too large.  That said, the replication will totally
> fall apart if it ever gets to a fraction of this, because this is the
> list of pages the source side needs to send again in addition to
> whatever *it* dirtied, as it is the state we've lost on the destination
> side by permitting the VM to run live.
> 
> The common case is that, when execution diverges, the dirtied pages on
> source and destination will be almost the same, so merging this on the
> source side shouldn't lead to many superfluous pages needing to be sent.

While I follow what you say, what I can't conclude is whether with this
you mean me to make any change to this first sentence of the description
(or even the patch itself).

>> --- a/tools/libs/guest/xg_sr_restore.c
>> +++ b/tools/libs/guest/xg_sr_restore.c
>> @@ -450,7 +450,8 @@ static int send_checkpoint_dirty_pfn_lis
>>      xc_interface *xch = ctx->xch;
>>      int rc = -1;
>>      unsigned int count, written;
>> -    uint64_t i, *pfns = NULL;
>> +    unsigned long i;
>> +    uint64_t *pfns = NULL;
>>      struct iovec *iov = NULL;
>>      struct xc_sr_record rec = {
>>          .type = REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST,
>> @@ -469,16 +470,28 @@ static int send_checkpoint_dirty_pfn_lis
>>  
>>      for ( i = 0, count = 0; i < ctx->restore.p2m_size; i++ )
>>      {
>> -        if ( test_bit(i, dirty_bitmap) )
>> -            count++;
>> +        if ( test_bit(i, dirty_bitmap) && !++count )
> 
> This is far too opaque logic.

This is an observation, without hint towards possible improvement.
I can attach a comment, but it's far from clear whether that's all
you're after.

> Its also entirely unnecessary...  All this loop is doing is calculating
> the size for the memory allocation below, and that can be done by using
> the stats output from xc_logdirty_control(), which means it doesn't want
> deleting in the earlier patch.

Only if there is a guarantee that the stats.dirty_count value hasn't
itself been truncated (or, as per the later patch, saturated) in the
hypervisor. Otherwise there may be more set bits in the bitmap, and
counting locally is still necessary. I generally think that anything
called "stats" may be used as guiding information, but not as precise
data. Yet the latter would be needed if you want to make memory
allocation depend on it.

Jan