* Fam Zheng (f...@redhat.com) wrote: > On Tue, 08/22 10:56, Peter Xu wrote: > > I haven't really encountered (c), but I think it's the migrate_cancel > > command that matters, which should not need BQL as well. > > There is bdrv_invalidate_cache_all() in migrate_cancel which clearly isn't > safe. > Is that if block unreachable in this case? If so we should assert, otherwise > this command is not okay to run without BQL.
Hmm yes that's a fairly recent addition to migrate_cancel - it used to be a simplish shutdown(); still I think it must be possible to get back to a simple shutdown() which is run directly with the cache stuff perhaps coming along later; actually the tricky bit is that the fd for the shutdown() isn't just a simple int, but is in an object which we have to make sure doesn't get freed while we do it. > Generically, what guarantee the thread-safety of a qmp command when you decide > BQL is not needed? In other words, how do you prove commands are safe without > BQL? I think almost every command accesses global state, but lock-free data > structures are rare AFAICT. I'm assuming there would initially be very few commands marked as lock-free, that were mostly trivially small. I was thinking that it might be possible to do a debug build with some checking as well; something like making the code that takes the bql check a per-thread flag, and assert if the flag is set. The monitor-threads could set the flag, so that if we fell down a path that tried to take the BQL we'd fail. Dave > Fam -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
