Skip to content
  • Igor Mitsyanko's avatar
    5fda043f
    exec.c: fix dirty bitmap reallocation · 5fda043f
    Igor Mitsyanko authored
    
    
    For each newly created RAM block, dirty bitmap is reallocated with g_realloc, which doesn't
    make any promises on initial content of new extra data in returned buffer. In theory,
    we initialize this new data with cpu_physical_memory_set_dirty_range() call. The
    problem is, cpu_physical_memory_set_dirty_range() has a side effect of incrementing
    ram_list.dirty_pages variable, but only for pages which are not already dirty. And
    page "cleanliness" is determined using the same not yet uninitialized dirty bitmap
    we've just reallocated. This results in inconsistency between real dirty page number
    and value in ram_list.dirty_pages variable, which in turn could (and will) result
    in errors during VM migration.
    Zero initialize new dirty bitmap bytes to fix this problem.
    
    Signed-off-by: default avatarIgor Mitsyanko <i.mitsyanko@samsung.com>
    Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
    5fda043f
    exec.c: fix dirty bitmap reallocation
    Igor Mitsyanko authored
    
    
    For each newly created RAM block, dirty bitmap is reallocated with g_realloc, which doesn't
    make any promises on initial content of new extra data in returned buffer. In theory,
    we initialize this new data with cpu_physical_memory_set_dirty_range() call. The
    problem is, cpu_physical_memory_set_dirty_range() has a side effect of incrementing
    ram_list.dirty_pages variable, but only for pages which are not already dirty. And
    page "cleanliness" is determined using the same not yet uninitialized dirty bitmap
    we've just reallocated. This results in inconsistency between real dirty page number
    and value in ram_list.dirty_pages variable, which in turn could (and will) result
    in errors during VM migration.
    Zero initialize new dirty bitmap bytes to fix this problem.
    
    Signed-off-by: default avatarIgor Mitsyanko <i.mitsyanko@samsung.com>
    Signed-off-by: default avatarBlue Swirl <blauwirbel@gmail.com>
Loading