Actions
Bug #56703
closed[pwl] AbstractWriteLog::m_lock vs ImageCtx::owner_lock lock ordering
% Done:
0%
Source:
Tags:
backport_processed
Backport:
pacific,quincy
Regression:
No
Severity:
3 - minor
Reviewed:
Description
AbstractWriteLog::m_lock vs ImageCtx::owner_lock lock ordering
AbstractWriteLog::periodic_stats() takes m_lock and ends up calling AbstractWriteLog::write_image_cache_state():
periodic_stats update_image_cache_state update_image_cache_state(Context*) write_image_cache_state
write_image_cache_state() takes owner_lock, so we have m_lock -> owner_lock order.
SnapshotCreateRequest::handle_notify_quiesce() takes owner_lock and ends up executing GuardedRequestFunctionContext callback:
handle_notify_quiesce send_suspend_requests send_suspend_aio WriteBlockImageDispatch::block_writes WriteBlockImageDispatch::flush_io ImageDispatchSpec::send ... WriteLogImageDispatch::flush AbstractWriteLog::flush internal_flush detain_guarded_request Context::complete GuardedRequestFunctionContext::finish
The callback may take m_lock, e.g. one defined in AbstractWriteLog::flush() or in AbstractWriteLog::internal_flush(), so we have owner_lock -> m_lock order.
Actions