Hi On Wed, Jan 23, 2019 at 4:39 PM Max Reitz <mre...@redhat.com> wrote: > > 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 >
Is anybody fixing this? Paolo suggestion seems right in general, but not easy to implement correctly for all chardevs. (C isn't helping!) I think this can be treated as a regression from commit 8258292e18c39480b64eba9f3551ab772ce29b5d, OOB monitor is now enabled by default (on socket chardev). -- Marc-André Lureau
