vmbus driver does not handle hyperv socket error properly

[Biswa96]

• Windows 10 version: 10.0.20211.1000
• Linux kernel version: 4.19.128-microsoft-standard
• Summary: The following code creates a AF_VSOCK socket. Then tries to connect with 1000 (random) port. The dmesg output shows unknown msgtype=23 and a backtrace output.
• Code sample, requires Linux kernel headers:

/* file: hvsock.c */
#include <stdio.h>
#include <sys/socket.h>
#include <assert.h>
#include <linux/vm_sockets.h>

int main(void)
{
    const int sockfd = socket(AF_VSOCK, SOCK_STREAM | SOCK_CLOEXEC, 0);
    assert(sockfd > 0);

    struct sockaddr_vm addr = { 0 };
    addr.svm_family = AF_VSOCK;
    addr.svm_port = 1000;
    addr.svm_cid = VMADDR_CID_HOST;
    const int connectRet = connect(sockfd, (struct sockaddr*)&addr, sizeof addr);
    assert(connectRet == 0);

    return 0;
}

• dmesg trace output:

[  172.113001] ------------[ cut here ]------------
[  172.118647] unknown msgtype=23
[  172.122388] WARNING: CPU: 1 PID: 0 at drivers/hv/vmbus_drv.c:937 vmbus_on_msg_dpc+0xff/0x1c0
[  172.128637] Modules linked in:
[  172.128637] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.128-microsoft-standard #1
[  172.128637] RIP: 0010:vmbus_on_msg_dpc+0xff/0x1c0
[  172.128637] Code: 00 83 fe 15 0f 86 5d ff ff ff 80 3d 26 d6 d0 00 00 0f 85 72 ff ff ff 48 c7 c7 ad 37 25 82 c6 05 12 d6 d0 00 01 e8 7b 48 89 ff <0f> 0b e9 58 ff ff ff 48 8b 3d ab 44 a4 00 ba 20 01 00 00 be 20 00
[  172.128637] RSP: 0018:ffff88807a503f28 EFLAGS: 00010282
[  172.128637] RAX: 0000000000000000 RBX: ffff88807a546000 RCX: ffffffff82440848
[  172.128637] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246
[  172.128637] RBP: 0000000000000000 R08: 000000000001cf77 R09: 000000000000000a
[  172.128637] R10: 0000000000000000 R11: ffffffff82b69e4d R12: 0000000000000001
[  172.128637] R13: ffff88807a546210 R14: 0000000000000040 R15: 0000000000000006
[  172.128637] FS:  0000000000000000(0000) GS:ffff88807a500000(0000) knlGS:0000000000000000
[  172.128637] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  172.128637] CR2: 00007f8a24fd8f60 CR3: 000000000240a004 CR4: 00000000001606a0
[  172.128637] Call Trace:
[  172.128637]  <IRQ>
[  172.128637]  tasklet_action_common.isra.21+0x5a/0x100
[  172.128637]  __do_softirq+0xde/0x2de
[  172.128637]  irq_exit+0xba/0xc0
[  172.128637]  hyperv_vector_handler+0x5f/0x80
[  172.128637]  hyperv_callback_vector+0xf/0x20
[  172.128637]  </IRQ>
[  172.128637] RIP: 0010:native_safe_halt+0xe/0x10
[  172.128637] Code: 1f 44 00 00 e9 c5 fe ff ff 0f 0b eb 94 0f 0b e9 04 ff ff ff 90 90 90 90 90 90 90 90 e9 07 00 00 00 0f 00 2d d4 1d 53 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d c4 1d 53 00 f4 c3 90 90 0f 1f 44 00
[  172.128637] RSP: 0018:ffffc9000008bec8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff0c
[  172.128637] RAX: ffffffff81ae69f0 RBX: 0000000000000001 RCX: ffffffff82441c10
[  172.128637] RDX: 0000000000008d5e RSI: ffffffff8243f878 RDI: 00000027e869cfe5
[  172.343804] RBP: 0000000000000001 R08: ffffffffff702911 R09: 000000000001eec0
[  172.343804] R10: 000000740b42abfd R11: 0000000000000000 R12: ffff88800fdca700
[  172.343804] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  172.343804]  ? __cpuidle_text_start+0x8/0x8
[  172.343804]  default_idle+0x1c/0x140
[  172.343804]  do_idle+0xe5/0x110
[  172.343804]  cpu_startup_entry+0x6f/0x80
[  172.343804]  start_secondary+0x195/0x1d0
[  172.343804]  secondary_startup_64+0xa4/0xb0
[  172.343804] ---[ end trace c97a6fadecf06440 ]---

• Other: I have tried this with local socket. It does not produce any trace and exits with assert message.

[therealkenc]

Looks like linux-behavior.

[Biswa96]

Looks like linux-behavior.

It looks like Microsoft behavior. 👇

When a Linux hv_sock app tries to connect to a Service GUID on which no
host app is listening, a recent host (RS3+) sends a
CHANNELMSG_TL_CONNECT_RESULT (23) message

Zero idea about what is going in between LxssManager, init and Linux kernel. Any explanation?

[therealkenc]

The explanation is the 4.19.128 Linux kernel emits those dmesgs unnecessarily, and they are now gone in more recent Linux kernels.

[Biswa96]

Understood. Just for curiosity, I would like to hear from any WSL devs.