block: Take graph lock for most of .bdrv_open
Most implementations of .bdrv_open first open their file child (which is an operation that internally takes the write lock and therefore we shouldn't hold the graph lock while calling it), and afterwards many operations that require holding the graph lock, e.g. for accessing bs->file. This changes block drivers that follow this pattern to take the graph lock after opening the child node. Signed-off-by:Kevin Wolf <kwolf@redhat.com> Message-ID: <20231027155333.420094-24-kwolf@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
Showing
- block/blkdebug.c 10 additions, 6 deletionsblock/blkdebug.c
- block/bochs.c 4 additions, 0 deletionsblock/bochs.c
- block/cloop.c 4 additions, 0 deletionsblock/cloop.c
- block/copy-before-write.c 2 additions, 0 deletionsblock/copy-before-write.c
- block/copy-on-read.c 2 additions, 2 deletionsblock/copy-on-read.c
- block/crypto.c 4 additions, 0 deletionsblock/crypto.c
- block/dmg.c 5 additions, 0 deletionsblock/dmg.c
- block/filter-compress.c 2 additions, 0 deletionsblock/filter-compress.c
- block/parallels.c 2 additions, 2 deletionsblock/parallels.c
- block/preallocate.c 4 additions, 0 deletionsblock/preallocate.c
- block/qcow.c 7 additions, 4 deletionsblock/qcow.c
- block/raw-format.c 4 additions, 2 deletionsblock/raw-format.c
- block/snapshot-access.c 3 additions, 0 deletionsblock/snapshot-access.c
- block/throttle.c 3 additions, 0 deletionsblock/throttle.c
- block/vdi.c 2 additions, 2 deletionsblock/vdi.c
- block/vpc.c 2 additions, 2 deletionsblock/vpc.c
Loading
Please register or sign in to comment