On Tue, Jan 20, 2026 at 03:54:19PM -0300, Fabiano Rosas wrote: > Peter Xu <[email protected]> writes: > > > On Fri, Jan 16, 2026 at 06:48:21PM -0300, Fabiano Rosas wrote: > >> Another one for the pile: > >> > >> #5 0x00007f0beda4fb32 in __assert_fail (assertion=0x55b8c3ed8cb8 "mode >= > >> 0 ...) at assert.c:103 > >> #6 0x000055b8c3a1d7a9 in migrate_mode () at ../migration/options.c:882 > >> #7 0x000055b8c3a1084e in fill_source_migration_info (info=0x55b8f1291650) > >> at ../migration/migration.c:1322 > >> #8 0x000055b8c3a10cae in qmp_query_migrate (errp=0x7fff5742ae80) at > >> ../migration/migration.c:1438 > >> #9 0x000055b8c3d4bc2a in qmp_marshal_query_migrate (args=0x55b8f11f2280, > >> ret=0x7f0becd25da8, errp=0x7f0becd25da0) at > >> qapi/qapi-commands-migration.c:48 > >> #10 0x000055b8c3d9a13b in do_qmp_dispatch_bh (opaque=0x7f0becd25e40) at > >> ../qapi/qmp-dispatch.c:128 > >> #11 0x000055b8c3dc6366 in aio_bh_call (bh=0x55b8f12922d0) at > >> ../util/async.c:173 > >> #12 0x000055b8c3dc6482 in aio_bh_poll (ctx=0x55b8f10741e0) at > >> ../util/async.c:220 > >> #13 0x000055b8c3da9832 in aio_poll (ctx=0x55b8f10741e0, blocking=false) at > >> ../util/aio-posix.c:719 > >> #14 0x000055b8c3cea017 in monitor_cleanup () at ../monitor/monitor.c:676 > >> #15 0x000055b8c39ef646 in qemu_cleanup (status=0) at > >> ../system/runstate.c:999 > >> #16 0x000055b8c3cec38e in qemu_default_main (opaque=0x0) at > >> ../system/main.c:51 > >> #17 0x000055b8c3cec430 in main (argc=33, argv=0x7fff5742b208) at > >> #../system/main.c:93 > >> > >> (gdb) p/x mode > >> $8 = 0xcccccccc > > > > What's the reproducer? Is it easy to reproduce? > > > > Just hammering some make check instances in parallel, as usual. > > > I wonder if current_migration released already, or if monitor should still > > process any QMP handler if the VM is shutting down.. > > > > monitor_cleanup says it will continue dispatching and just never send a > response to the command. It seems migration will need it's own way of > tracking this. > > Maybe as a first step we could clear current_migration at > migration_instance_finalize(). > (I see device-introspect-test doesn't like it. I'll look into it) > > > Is this only happening after this series applied? I can't yet see how the > > threadify affected it.. > > No, sorry, I posted here because I think this affects this series' > assumptions about the BQL.
Aha, you reminded me on this work, remember to check it out (I forgot most of it.. as usual..): https://lore.kernel.org/qemu-devel/[email protected] I also recall besides the singleton idea, we can also take a mutex and release current_migration at finalize(), then fetch current_migration will instead need to take a refcount and also with mutex held. Anyway, thanks for looking into it. Now, it's all yours. :) -- Peter Xu
