[vbox-dev] Guests hang when accessing a shared FIFO on the host

[Lukas Lueg]

Hi,

this is basically a bug report, I don't want to share all my personal
information that is required to post a simple bug report though. I for
one still welcome our new Oracle overlords.

I've a MacOS host running 4.3.20 r96996. I've noticed that a directory
containing a named pipe causes the Windows guest to stall if something
tries to access that file's content or the node itself (e.g. trying to
delete it in explorer.exe). This is especially annoying since any
directory shared from the MacOS-host to the guest could contain a
named pipe disguised as a zero-bytes file. Just browsing into those
directories can cause the VM to start consuming 99% cpu time on all
cpus and it having to be SIGKILLed.

I could reproduce this for Linux guests also:

- On the host, create a new directory and put a named pipe there (e.g.
"mkdir -p $HOME/tmp && mkfifo $HOME/tmp/myfifo"). Do not write
anything to the pipe yet.
- Create a share to the guest, running Linux in this example. It
doesn't matter if the share is readonly or not
- Mount the share on the guest (e.g. "mkdir $HOME/tmp && sudo
mount.vboxsf tmp tmp")
- On the guest, try to read from $HOME/tmp/myfifo directly or have
some program call lstat() on the directory. The call will block and so
will everything else that tries to access anything in the shared
folder from now on. A Windows-guest becomes unusable, Linux is more
forgiving. You can unblock the call by writing to the pipe on the
host, causing a protocol error on the other end.

Here is a strace-log of the Nemo file manager trying to display the
content of $HOME/tmp, containing a single FIFO. Just browsing into the
shared folder causes Nemo to block and become unresponsive; other
processes that try to access the share (not just the FIFO itself) in
any way will from then on also block (e.g. a simple "ls $HOME/tmp").

.....
1421928311.443901 munmap(0x7f73bc07d000, 4096) = 0 <0.000022>
1421928311.443960 inotify_add_watch(9, "/home/slave/t",
IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVE|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR)
= 22 <0.000017>
1421928311.444028 lstat("/home/slave/t/.hidden", 0x7fff51b02590) = -1
ENOENT (No such file or directory) <8.163500>
1421928319.612127 futex(0x18db794, FUTEX_WAKE_OP_PRIVATE, 1, 1,
0x18db790, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 <0.000050>
1421928319.612305 futex(0x19517b0, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000921>
1421928319.614000 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295)
= 1 ([{fd=3, revents=POLLIN|POLLOUT}]) <0.000366>
....

Notice that the lstat()-call takes around eight seconds within the
syscall. By this time, I had written some garbage to $HOME/tmp/myfifo
on the host, which unlocks Nemo and everything else.


I'd suspect that running into a FIFO shared to the guest can cause
grievance to handle correctly. The situation where *all* access to the
share blocks once the guest encounters a FIFO and that the VM may run
at 99% cpu time on all CPUs should be avoided.


Best regards
Lukas