[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Segfaults in chardev due to races
From: |
Marc-André Lureau |
Subject: |
Re: [Qemu-devel] Segfaults in chardev due to races |
Date: |
Wed, 6 Feb 2019 19:38:18 +0100 |
Hi
On Wed, Jan 23, 2019 at 4:39 PM Max Reitz <address@hidden> 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
- Re: [Qemu-devel] Segfaults in chardev due to races,
Marc-André Lureau <=