#
1f051dcb |
| 27-Oct-2023 |
Kevin Wolf <kwolf@redhat.com> |
block: Protect bs->file with graph_lock
Almost all functions that access bs->file already take the graph lock now. Add locking to the remaining users and finally annotate the struct field itself as
block: Protect bs->file with graph_lock
Almost all functions that access bs->file already take the graph lock now. Add locking to the remaining users and finally annotate the struct field itself as protected by the graph lock.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231027155333.420094-25-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
#
a4b740db |
| 27-Oct-2023 |
Kevin Wolf <kwolf@redhat.com> |
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 ho
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>
show more ...
|
#
79a55866 |
| 27-Oct-2023 |
Kevin Wolf <kwolf@redhat.com> |
block: Add missing GRAPH_RDLOCK annotations
This adds GRAPH_RDLOCK to some driver callbacks that are already called with the graph lock held, and which will need the annotation because they access b
block: Add missing GRAPH_RDLOCK annotations
This adds GRAPH_RDLOCK to some driver callbacks that are already called with the graph lock held, and which will need the annotation because they access bs->file, but don't have it yet.
This also covers a few callbacks that were not marked GRAPH_RDLOCK before, but where updating BlockDriver is trivially possible.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231027155333.420094-21-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
#
1f051dcb |
| 27-Oct-2023 |
Kevin Wolf <kwolf@redhat.com> |
block: Protect bs->file with graph_lock
Almost all functions that access bs->file already take the graph lock now. Add locking to the remaining users and finally annotate the struct field itself as
block: Protect bs->file with graph_lock
Almost all functions that access bs->file already take the graph lock now. Add locking to the remaining users and finally annotate the struct field itself as protected by the graph lock.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231027155333.420094-25-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
#
a4b740db |
| 27-Oct-2023 |
Kevin Wolf <kwolf@redhat.com> |
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 ho
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>
show more ...
|
#
79a55866 |
| 27-Oct-2023 |
Kevin Wolf <kwolf@redhat.com> |
block: Add missing GRAPH_RDLOCK annotations
This adds GRAPH_RDLOCK to some driver callbacks that are already called with the graph lock held, and which will need the annotation because they access b
block: Add missing GRAPH_RDLOCK annotations
This adds GRAPH_RDLOCK to some driver callbacks that are already called with the graph lock held, and which will need the annotation because they access bs->file, but don't have it yet.
This also covers a few callbacks that were not marked GRAPH_RDLOCK before, but where updating BlockDriver is trivially possible.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231027155333.420094-21-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
#
e0ee3a8f |
| 25-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
cpr: relax blockdev migration blockers
Some blockdevs block migration because they do not support sharing across hosts and/or do not support dirty bitmaps. These prohibitions do not apply if the ol
cpr: relax blockdev migration blockers
Some blockdevs block migration because they do not support sharing across hosts and/or do not support dirty bitmaps. These prohibitions do not apply if the old and new qemu processes do not run concurrently, and if new qemu starts on the same host as old, which is the case for cpr. Narrow the scope of these blockers so they only apply to normal mode. They will not block cpr modes when they are added in subsequent patches.
No functional change until a new mode is added.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-4-git-send-email-steven.sistare@oracle.com>
show more ...
|
#
e0ee3a8f |
| 25-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
cpr: relax blockdev migration blockers
Some blockdevs block migration because they do not support sharing across hosts and/or do not support dirty bitmaps. These prohibitions do not apply if the ol
cpr: relax blockdev migration blockers
Some blockdevs block migration because they do not support sharing across hosts and/or do not support dirty bitmaps. These prohibitions do not apply if the old and new qemu processes do not run concurrently, and if new qemu starts on the same host as old, which is the case for cpr. Narrow the scope of these blockers so they only apply to normal mode. They will not block cpr modes when they are added in subsequent patches.
No functional change until a new mode is added.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-4-git-send-email-steven.sistare@oracle.com>
show more ...
|
#
e0ee3a8f |
| 25-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
cpr: relax blockdev migration blockers
Some blockdevs block migration because they do not support sharing across hosts and/or do not support dirty bitmaps. These prohibitions do not apply if the ol
cpr: relax blockdev migration blockers
Some blockdevs block migration because they do not support sharing across hosts and/or do not support dirty bitmaps. These prohibitions do not apply if the old and new qemu processes do not run concurrently, and if new qemu starts on the same host as old, which is the case for cpr. Narrow the scope of these blockers so they only apply to normal mode. They will not block cpr modes when they are added in subsequent patches.
No functional change until a new mode is added.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-4-git-send-email-steven.sistare@oracle.com>
show more ...
|
#
c8a7fc51 |
| 18-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_blocker, migration code can free the Error and clear the client handle, simplifying client code. It also simplifies the migrate_del_blocker call site.
In addition, this is a pre-requisite for a proposed future patch that would add a mode argument to migration requests to support live update, and maintain a list of blockers for each mode. A blocker may apply to a single mode or to multiple modes, and passing Error** will allow one Error object to be registered for multiple modes.
No functional change.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Tested-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1697634216-84215-1-git-send-email-steven.sistare@oracle.com>
show more ...
|
#
c8a7fc51 |
| 18-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_blocker, migration code can free the Error and clear the client handle, simplifying client code. It also simplifies the migrate_del_blocker call site.
In addition, this is a pre-requisite for a proposed future patch that would add a mode argument to migration requests to support live update, and maintain a list of blockers for each mode. A blocker may apply to a single mode or to multiple modes, and passing Error** will allow one Error object to be registered for multiple modes.
No functional change.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Tested-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1697634216-84215-1-git-send-email-steven.sistare@oracle.com>
show more ...
|
#
c8a7fc51 |
| 18-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_blocker, migration code can free the Error and clear the client handle, simplifying client code. It also simplifies the migrate_del_blocker call site.
In addition, this is a pre-requisite for a proposed future patch that would add a mode argument to migration requests to support live update, and maintain a list of blockers for each mode. A blocker may apply to a single mode or to multiple modes, and passing Error** will allow one Error object to be registered for multiple modes.
No functional change.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Tested-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1697634216-84215-1-git-send-email-steven.sistare@oracle.com>
show more ...
|
Revision tags: v8.1.2 |
|
#
4026f1c4 |
| 29-Sep-2023 |
Kevin Wolf <kwolf@redhat.com> |
block: Mark bdrv_get_parent_name() and callers GRAPH_RDLOCK
This adds GRAPH_RDLOCK annotations to declare that callers of bdrv_get_parent_name() need to hold a reader lock for the graph because it a
block: Mark bdrv_get_parent_name() and callers GRAPH_RDLOCK
This adds GRAPH_RDLOCK annotations to declare that callers of bdrv_get_parent_name() need to hold a reader lock for the graph because it accesses the parents list of a node.
For some places, we know that they will hold the lock, but we don't have the GRAPH_RDLOCK annotations yet. In this case, add assume_graph_lock() with a FIXME comment. These places will be removed once everything is properly annotated.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20230929145157.45443-13-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
Revision tags: v8.1.2 |
|
#
4026f1c4 |
| 29-Sep-2023 |
Kevin Wolf <kwolf@redhat.com> |
block: Mark bdrv_get_parent_name() and callers GRAPH_RDLOCK
This adds GRAPH_RDLOCK annotations to declare that callers of bdrv_get_parent_name() need to hold a reader lock for the graph because it a
block: Mark bdrv_get_parent_name() and callers GRAPH_RDLOCK
This adds GRAPH_RDLOCK annotations to declare that callers of bdrv_get_parent_name() need to hold a reader lock for the graph because it accesses the parents list of a node.
For some places, we know that they will hold the lock, but we don't have the GRAPH_RDLOCK annotations yet. In this case, add assume_graph_lock() with a FIXME comment. These places will be removed once everything is properly annotated.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20230929145157.45443-13-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
Revision tags: v8.1.1, v7.2.6, v8.0.5 |
|
#
a98b260a |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: naive implementation of parallels_co_pwrite_zeroes
The zero flag is missed in the Parallels format specification. We can resort to discard if we have no backing file.
Signed-off-by: Deni
parallels: naive implementation of parallels_co_pwrite_zeroes
The zero flag is missed in the Parallels format specification. We can resort to discard if we have no backing file.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
c54fb435 |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: naive implementation of parallels_co_pdiscard
* Discarding with backing stores is not supported by the format. * There is no buffering/queueing of the discard operation. * Only operations
parallels: naive implementation of parallels_co_pdiscard
* Discarding with backing stores is not supported by the format. * There is no buffering/queueing of the discard operation. * Only operations aligned to the cluster are supported.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
66d201dd |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: improve readability of allocate_clusters
Replace 'space' representing the amount of data to preallocate with 'bytes'.
Rationale: * 'space' at each place is converted to bytes * the unit
parallels: improve readability of allocate_clusters
Replace 'space' representing the amount of data to preallocate with 'bytes'.
Rationale: * 'space' at each place is converted to bytes * the unit is more close to the variable name
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
3ac10d19 |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: naive implementation of allocate_clusters with used bitmap
The access to the bitmap is not optimized completely.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Iva
parallels: naive implementation of allocate_clusters with used bitmap
The access to the bitmap is not optimized completely.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
eeb1e6dc |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: update used bitmap in allocate_cluster
We should extend the bitmap if the file is extended and set the bit in the image used bitmap once the cluster is allocated. Sanity check at that mom
parallels: update used bitmap in allocate_cluster
We should extend the bitmap if the file is extended and set the bit in the image used bitmap once the cluster is allocated. Sanity check at that moment also looks like a good idea.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
73194d3f |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: accept multiple clusters in mark_used()
This would be useful in the next patch in allocate_clusters(). This change would not imply serious performance drawbacks as usually image is full o
parallels: accept multiple clusters in mark_used()
This would be useful in the next patch in allocate_clusters(). This change would not imply serious performance drawbacks as usually image is full of data or are at the end of the bitmap.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
e185100f |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: collect bitmap of used clusters at open
If the operation is failed, we need to check image consistency if the problem is not about memory allocation.
Bitmap adjustments in allocate_clust
parallels: collect bitmap of used clusters at open
If the operation is failed, we need to check image consistency if the problem is not about memory allocation.
Bitmap adjustments in allocate_cluster are not performed yet. They worth to be separate. This was proven useful during debug of this series. Kept as is for future bissecting.
It should be specifically noted that used bitmap must be recalculated if data_off has been fixed during image consistency check.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
6f2206b0 |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: fix broken parallels_check_data_off()
Once we have repaired data_off field in the header we should update s->data_start which is calculated on the base of it.
Signed-off-by: Denis V. Lun
parallels: fix broken parallels_check_data_off()
Once we have repaired data_off field in the header we should update s->data_start which is calculated on the base of it.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
a398275e |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: create mark_used() helper which sets bit in used bitmap
This functionality is used twice already and next patch will add more code with it.
Signed-off-by: Denis V. Lunev <den@openvz.org>
parallels: create mark_used() helper which sets bit in used bitmap
This functionality is used twice already and next patch will add more code with it.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
8f5f5326 |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: refactor path when we need to re-check image in parallels_open
More conditions follows thus the check should be more scalable.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by:
parallels: refactor path when we need to re-check image in parallels_open
More conditions follows thus the check should be more scalable.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|
#
e17b9d08 |
| 18-Sep-2023 |
Denis V. Lunev <den@openvz.org> |
parallels: return earlier from parallels_open() function on error
At the beginning of the function we can return immediately until we really allocate s->header.
Signed-off-by: Denis V. Lunev <den@o
parallels: return earlier from parallels_open() function on error
At the beginning of the function we can return immediately until we really allocate s->header.
Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com>
show more ...
|