aboutsummaryrefslogtreecommitdiff
path: root/ebpf
diff options
context:
space:
mode:
authorJohn Snow <jsnow@redhat.com>2021-11-11 09:37:15 -0500
committerJohn Snow <jsnow@redhat.com>2021-11-16 14:26:36 -0500
commitf26bd6ff21df2f1d155ca17eef360423b706ab7f (patch)
tree2b6702e32eaac8f40ae2fa3f8230fbc1f0520439 /ebpf
parent2b22e7540d6ab4efe82d442363e3fc900cea6584 (diff)
downloadqemu-f26bd6ff21df2f1d155ca17eef360423b706ab7f.zip
qemu-f26bd6ff21df2f1d155ca17eef360423b706ab7f.tar.gz
qemu-f26bd6ff21df2f1d155ca17eef360423b706ab7f.tar.bz2
python/aqmp: Fix disconnect during capabilities negotiation
If we receive ConnectionResetError (ECONNRESET) while attempting to perform capabilities negotiation -- prior to the establishment of the async reader/writer tasks -- the disconnect function is not aware that we are in an error pathway. As a result, when attempting to close the StreamWriter, we'll see the same ConnectionResetError that caused us to initiate a disconnect in the first place, which will cause the disconnect task itself to fail, which emits a CRITICAL logging event. I still don't know if there's a smarter way to check to see if an exception received at this point is "the same" exception as the one that caused the initial disconnect, but for now the problem can be avoided by improving the error pathway detection in the exit path. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20211111143719.2162525-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'ebpf')
0 files changed, 0 insertions, 0 deletions