Stratos Psomadakis <pso...@grnet.gr> writes:
> Commit cdaa86a54 ("Add G_IO_HUP handler for socket chardev") exposed a
> bug in the way the HMP monitor handles its input. When a client closes
> the connection to the monitor, tcp_chr_read() will catch the HUP
> 'signal' and call tcp_chr_disconnect() to close the server-side
> connection too.
Your wording suggests SIGUP, but that's misleading. Suggest
"tcp_chr_read() will detect the G_IO_HUP condition, and call".
> Due to the fact that monitor reads 1 byte at a time (for
> each tcp_chr_read()), the monitor readline state / buffers can be left
> in an inconsistent state (i.e. a half-finished command).
The state is not really inconsistent, there's just junk left in
rs->cmd_buf[].
> Thus, without
> calling readline_restart() on mon->rs upon CHR_EVENT_CLOSED, future HMP
> commands will fail.
To make sure I understand you correctly: when you connect again, any
leftover junk is prepended to your input, which messes up your first
command. Correct?
> Signed-off-by: Stratos Psomadakis <pso...@grnet.gr>
> Signed-off-by: Dimitris Aragiorgis <dim...@grnet.gr>
> ---
> monitor.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/monitor.c b/monitor.c
> index 34cee74..7857300 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -5252,6 +5252,7 @@ static void monitor_event(void *opaque, int event)
> break;
>
> case CHR_EVENT_CLOSED:
> + readline_restart(mon->rs);
> mon_refcount--;
> monitor_fdsets_cleanup();
> break;
Patch looks good to me.
