VirtualBox

Opened 5 years ago

Last modified 3 years ago

#19133 assigned defect

Mac-hosted VM lockup when guest opens a named pipe in a shared folder — at Version 3

Reported by: lesha Owned by: Frank Batschulat (Oracle)
Component: shared folders Version: VirtualBox 6.0.14
Keywords: named pipe, fifo, lockup Cc:
Guest type: all Host type: all

Description (last modified by Frank Batschulat (Oracle))

I discovered this bug because I was rsyncing a shared folder containing a named pipe, and this hung my machine.

Repro steps:

  • Set up a Linux guest on a Mac host. I have Ubuntu 18.04 running on VBox 6.0.14 (latest stable as of now).
  • Set up a shared folder
  • On the host, mkfifo TEST_PIPE in the folder
  • On the guest, cat TEST_PIPE

At this point, the guest is (partially) locked up. Specifically:

  • Ctrl-C nor SIGKILL will work for cat — it is hung in D state, unkillable
  • Any process touching the shared folder hangs likewise
  • dmesg will show the following stack for the hung cat https://pastebin.com/WjKQaZys [1]
  • The guest cannot be cleanly rebooted because shutdown requires tearing down the guest additions module, which is blocked on talking to the VM.
  • Powering off the VM (not from the guest, but from the UI!) will hang.

So this is not a hang in guest additions, but in the VM code itself.

My guess is that the thread handling shared folders is locked up trying to read from the named pipe.

What confirms this is that the hang is resolved the moment that I do echo > TEST_PIPE on the host.

The reason this is not expected behavior is that the guest sees the named pipe as a regular file:

$ ls -l TEST_PIPE -rwxrwx--- 1 root vboxsf 0 Dec 6 16:21 TEST_PIPE

Two fixes seem possible:

  • Make named pipes act as true named pipes to the host. If you google "vboxsf named pipe", this is actually a feature that was previously requested.
  • Make the open syscall fail in this context. This is worse than working pipes, but better than a lockup. At the moment, data does not actually travel down the named pipe, if the host does echo foo > TEST_PIPE and the guest does cat TEST_PIPE, the guest simply says cat: TEST_PIPE: Protocol error.

[1]

$ sudo cat /proc/7376/stack
[<0>] rtR0SemEventMultiLnxWait.isra.2+0x33d/0x370 [vboxguest]
[<0>] VBoxGuest_RTSemEventMultiWaitEx+0xe/0x10 [vboxguest]
[<0>] VBoxGuest_RTSemEventMultiWait+0x28/0x30 [vboxguest]
[<0>] vgdrvHgcmAsyncWaitCallbackWorker+0x1c3/0x210 [vboxguest]
[<0>] VGDrvCommonIoCtl+0x489/0x18e0 [vboxguest]
[<0>] VBoxGuestIDC+0x149/0x160 [vboxguest]
[<0>] VbglR0IdcCallRaw+0x13/0x20 [vboxsf]
[<0>] VbglR0HGCMFastCall+0x1c/0x20 [vboxsf]
[<0>] vbsf_reg_open+0x291/0x4f0 [vboxsf]
[<0>] do_dentry_open+0x1c2/0x310
[<0>] vfs_open+0x4f/0x80
[<0>] path_openat+0x6bf/0x1900
[<0>] do_filp_open+0x9b/0x110
[<0>] do_sys_open+0x1bb/0x2c0
[<0>] SyS_openat+0x14/0x20
[<0>] do_syscall_64+0x73/0x130
[<0>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<0>] 0xffffffffffffffff

Change History (2)

comment:1 by Frank Batschulat (Oracle), 5 years ago

Owner: set to Frank Batschulat (Oracle)
Status: newaccepted

thanks for this excellent bug report!

THe fix strategy is likely going to be to show the hosts file as a pipe (currently it is shown as a regular file) but do not support any actvity on such a pipe file from the guest side and fail such attempts in the guest with ENOTSUP.

Last edited 5 years ago by Frank Batschulat (Oracle) (previous) (diff)

comment:3 by Frank Batschulat (Oracle), 4 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette