On 22.12.18 10:17, Paolo Bonzini wrote: > On 21/12/18 23:31, Max Reitz wrote: >> I suppose the issue is that QMP events are sent by one thread, and >> client disconnects are handled by a different one. So if a QMP event is >> sent while a client disconnects concurrently, races may occur; and the >> only protection against concurrent access appears to be the >> chr_write_lock, which I don't think is enough. > > I think disconnection (tcp_chr_disconnect) has to take the > chr_write_lock too.
That seems to fix the issue for me (can also be reproduced by running iotest 169 in parallel), but how should this be implemented? I suppose tcp_chr_disconnect() can't really take the lock itself, because it's called by tcp_chr_write() which is invoked with the lock held. Max
signature.asc
Description: OpenPGP digital signature