| Message ID | 20221116135331.3052923-1-eesposit@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Protect the block layer with a rwlock: part 2 | expand |
Ok, as I expected simple changes in a previous based-on serie provoke a cascade of changes that inevitably affect these patches too. While I strongly suggest to have an initial look at these patches because it gives an idea on what am I trying to accomplish, I would not go looking at nitpicks and trivial errors that came up from the based-on series (ie "just as in the previous serie, fix this"). The order of the series is: 1. Still more coroutine and various fixes in block layer 2. Protect the block layer with a rwlock: part 1 3. Protect the block layer with a rwlock: part 2 4. Protect the block layer with a rwlock: part 3 Thank you, Emanuele Am 16/11/2022 um 14:53 schrieb Emanuele Giuseppe Esposito: > Please read "Protect the block layer with a rwlock: part 1" for an additional > introduction and aim of this series. > > This second part aims to add the graph rdlock to the BlockDriver functions > that already run in coroutine context and are classified as IO. > Such functions will recursively traverse the BlockDriverState graph, therefore > they need to be protected with the rdlock. > > Based-on: <20221116134850.3051419-1-eesposit@redhat.com> > > Thank you, > Emanuele > > Emanuele Giuseppe Esposito (6): > block: assert that bdrv_co_create is always called with graph rdlock > taken > block: assert that BlockDriver->bdrv_co_{amend/create} are called with > graph rdlock taken > block: assert that BlockDriver->bdrv_co_copy_range_{from/to} is always > called with graph rdlock taken > block/dirty-bitmap: assert that BlockDriver->bdrv_co_*_dirty_bitmap > are always called with graph rdlock taken > block/io: assert that BlockDriver->bdrv_co_*_snapshot_* are always > called with graph rdlock taken > block: assert that BlockDriver->bdrv_co_delete_file is always called > with graph rdlock taken > > block.c | 2 ++ > block/amend.c | 1 + > block/block-backend.c | 2 ++ > block/create.c | 1 + > block/dirty-bitmap.c | 2 ++ > block/io.c | 7 +++++++ > include/block/block_int-common.h | 14 +++++++++++++- > qemu-img.c | 4 +++- > 8 files changed, 31 insertions(+), 2 deletions(-) >
Please read "Protect the block layer with a rwlock: part 1" for an additional introduction and aim of this series. This second part aims to add the graph rdlock to the BlockDriver functions that already run in coroutine context and are classified as IO. Such functions will recursively traverse the BlockDriverState graph, therefore they need to be protected with the rdlock. Based-on: <20221116134850.3051419-1-eesposit@redhat.com> Thank you, Emanuele Emanuele Giuseppe Esposito (6): block: assert that bdrv_co_create is always called with graph rdlock taken block: assert that BlockDriver->bdrv_co_{amend/create} are called with graph rdlock taken block: assert that BlockDriver->bdrv_co_copy_range_{from/to} is always called with graph rdlock taken block/dirty-bitmap: assert that BlockDriver->bdrv_co_*_dirty_bitmap are always called with graph rdlock taken block/io: assert that BlockDriver->bdrv_co_*_snapshot_* are always called with graph rdlock taken block: assert that BlockDriver->bdrv_co_delete_file is always called with graph rdlock taken block.c | 2 ++ block/amend.c | 1 + block/block-backend.c | 2 ++ block/create.c | 1 + block/dirty-bitmap.c | 2 ++ block/io.c | 7 +++++++ include/block/block_int-common.h | 14 +++++++++++++- qemu-img.c | 4 +++- 8 files changed, 31 insertions(+), 2 deletions(-)