On (Tue) 17 Dec 2013 [11:12:02], Gal Hammer wrote:
> On 16/12/2013 22:32, Amit Shah wrote:
> >On (Sun) 15 Dec 2013 [12:26:37], Gal Hammer wrote:
> >>Fix a bug that was introduced in commit 386a5a1e. A removal of a device
> >>set the chr handlers to NULL. However when the device is plugged back,
> >>its read callback is not restored so data can't be transferred from the
> >>host to the guest (e.g. via the virtio-serial port).
> >>
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1027181
> >>
> >>Signed-off-by: Gal Hammer <gham...@redhat.com>
> >>
> >>---
> >> qemu-char.c | 17 +++++++++++++++--
> >> 1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >>V4: - Same as V3, but this time done right.
> >>
> >>V3: - fix a typo in comment.
> >> - move the revision history after the "signed-off-by" tag.
> >>
> >>V2: - do not call chr_update_read_handler on device removal.
> >> - add asserts to verify chr_update_read_handler is not called
> >> with an assigned fd_in_tag to prevent fd leaks.
> >> - update fd and udp backends' chr_update_read_handler function
> >> so it won't remove fd_in to prevent a double release.
> >
> >Looks like you missed the pty backend. Can't blame you -- this
> >chardev stuff is really messy. pty is doing is own handling + polling
> >+ HUP detection, which really is equally applicable to tcp and udp as
> >well.
>
> As far as I could tell the pty backend doesn't suffer from this
> issue. That's why I didn't change anything there.
pty_chr_update_read_handler() calls pty_chr_state(), which calls
remove_fd_in_watch().
Amit
