qcow2 api not secured by mutex lock

[Vladimir Sementsov-Ogievskiy]

Hi!

Some time ago, we've faced and fixed the fact that qcow2 bitmap api doesn't
call qcow2_co_mutex_lock, before accessing qcow2 metadata. This was solved by
moving qcow2_co_remove_persistent_dirty_bitmap and
qcow2_co_can_store_new_dirty_bitmap to coroutine and call qcow2_co_mutex_lock.

Now I decided to look at big picture (it is attached).

Boxes are qcow2 driver api, green border means that function calls 
qcow2_co_mutex_lock
(it doesn't guarantee, that exactly child node call is locked, but it is 
something).

In the picture there are just all functions, calling qcow2_cache_get/put.. Not 
all the
functions, that needs locking, but again, it is something.

So, accordingly to the picture, it seems that the following functions lacks 
locking:

qcow2_co_create

qcow2_snapshot_*
   (but it is both drained and aio context locked, so should be safe, yes?)

qcow2_reopen_bitmaps_rw
qcow2_store_persistent_dirty_bitmaps

qcow2_amend_options

qcow2_make_empty

===

Checking green nodes:

qcow2_co_invalidate_cache actually calls qcow2_close unlocked, it's another 
reason to fix qcow2_store_persistent_dirty_bitmaps

qcow2_write_snapshots actually called unlocked from 
qcow2_check_fix_snapshot_table.. It seems unsafe.

===


Not complete audit of course.. What do you think about it? I think, I at least 
should move
qcow2_store_persistent_dirty_bitmaps and qcow2_reopen_bitmaps_rw to coroutine,
like qcow2_co_remove_persistent_dirty_bitmap.


-- 
Best regards,
Vladimir

master-block-qcow2-filtered.svg
Description: master-block-qcow2-filtered.svg