On Thu, Jul 02, 2026 at 04:07:38PM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > > On Wed, Jul 01, 2026 at 08:32:06AM +0200, Markus Armbruster wrote: > > [...] > > >> >> static void monitor_qmp_event(void *opaque, QEMUChrEvent event) > >> >> { > >> >> QDict *data; > >> >> MonitorQMP *mon = opaque; > >> >> > >> >> + /* Protect against race if a client drops & quickly > >> >> + * reconnects - we'll have the delete BH scheduled > >> >> + * so must not honour a new open request > >> >> + */ > >> >> + if (mon->delete_pending) { > >> >> + return; > >> >> + } > >> > >> Consider "something happens between setting @delete_pending and monitor > >> destruction that triggers the event" and "same thing happens after > >> destruction". Any observable differences in behavior? > >> > >> Are there any other monitor interactions that might need similar > >> special-casing when @delete_pending? > > > > When the BH deletes the monitor object, it will disconnect the > > chardev handlers. So there is no possibility of monitor_qmp_event > > being called after the monitor QOM destruction is complete. The > > only race is between this method and the start of the BH. > > Add this completeness argument to the commit message?
Ok With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
