Daniel P. Berrangé <berrange@redhat.com> 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?