netdev - TCP/IP connections sometimes stop retransmitting packets (in nested virtualization case)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1054a24529be44e11d65e61d8760f7c59dfa073b.camel@redhat.com>
Date:   Sun, 17 Oct 2021 13:50:51 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     netdev@...r.kernel.org
Cc:     "J. Bruce Fields" <bfields@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>, qemu-devel@...gnu.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Michael Tsirkin <mtsirkin@...hat.com>,
        David Gilbert <dgilbert@...hat.com>
Subject: TCP/IP connections sometimes stop retransmitting packets (in nested
 virtualization case)

Hi!

This is a follow up mail to my mail about NFS client deadlock I was trying to debug last week:
https://lore.kernel.org/all/e10b46b04fe4427fa50901dda71fb5f5a26af33e.camel@redhat.com/T/#u

I strongly believe now that this is not related to NFS, but rather to some issue in networking stack and maybe
to somewhat non standard .config I was using for the kernels which has many advanced networking options disabled
(to cut on compile time).
This is why I choose to start a new thread about it.

Regarding the custom .config file, in particular I disabled CONFIG_NET_SCHED and CONFIG_TCP_CONG_ADVANCED. 
Both host and the fedora32 VM run the same kernel with those options disabled.

My setup is a VM (fedora32) which runs Win10 HyperV VM inside, nested, which in turn runs a fedora32 VM
(but I was able to reproduce it with ordinary HyperV disabled VM running in the same fedora 32 VM)

The host is running a NFS server, and the fedora32 VM runs a NFS client which is used to read/write to a qcow2 file
which contains the disk of the nested Win10 VM. The L3 VM which windows VM optionally
runs, is contained in the same qcow2 file.

I managed to capture (using wireshark) packets around the failure in both L0 and L1.
The trace shows fair number of lost packets, a bit more than I would expect from communication that is running on the same host, 
but they are retransmitted and don't cause any issues until the moment of failure.

The failure happens when one packet which is sent from host to the guest,
is not received by the guest (as evident by the L1 trace, and by the following SACKS from the guest which exclude this packet), 
and then the host (on which the NFS server runs) never attempts to re-transmit it.

The host keeps on sending further TCP packets with replies to previous RPC calls it received from the fedora32 VM,
with an increasing sequence number, as evident from both traces, and the fedora32 VM keeps on SACK'ing those received packets, 
patiently waiting for the retransmission.

After around 12 minutes (!), the host RSTs the connection.

It is worth mentioning that while all of this is happening, the fedora32 VM can become hung if one attempts to access the files 
on the NFS share because effectively all NFS communication is blocked on TCP level.

I attached an extract from the two traces  (in L0 and L1) around the failure up to the RST packet.

In this trace the second packet with TCP sequence number 1736557331 (first one was empty without data) is not received by the guest
and then never retransmitted by the host.

Also worth noting that to ease on storage I captured only 512 bytes of each packet, but wireshark
notes how many bytes were in the actual packet.

Best regards,
	Maxim Levitsky

Download attachment "L0_packets.pcapng" of type "application/x-pcapng" (97208 bytes)

Download attachment "L1_packets.pcapng" of type "application/x-pcapng" (92092 bytes)