On Wed, May 10, 2023 at 10:36:01PM +0200, Kevin Wolf wrote: > > There are some conditions under which we don't actually need to do > anything for taking a reader lock: Writing the graph is only possible > from the main context while holding the BQL. So if a reader is running > in the main context under the BQL and knows that it won't be interrupted > until the next writer runs, we don't actually need to do anything. > > This is the case if the reader code neither has a nested event loop > (this is forbidden anyway while you hold the lock) nor is a coroutine > (because a writer could run when the coroutine has yielded). > > These conditions are exactly what bdrv_graph_rdlock_main_loop() asserts. > They are not fulfilled in bdrv_graph_co_rdlock(), which always runs in a > coroutine. > > This deletes the shortcuts in bdrv_graph_co_rdlock() that skip taking > the reader lock in the main thread. > > Reported-by: Fiona Ebner <f.eb...@proxmox.com> > Signed-off-by: Kevin Wolf <kw...@redhat.com> > --- > block/graph-lock.c | 10 ---------- > 1 file changed, 10 deletions(-)
Bug fix by deletion is always fun. Reviewed-by: Eric Blake <ebl...@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
