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

Reply via email to