Bug 255208 - FATAL crash/reboot upon trying to mount a VirtualBox shared folder in FreeBSD guest (13.0 RELEASE)
Summary: FATAL crash/reboot upon trying to mount a VirtualBox shared folder in FreeBSD...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Virtualbox Team (Nobody)
URL:
Keywords: crash, needs-qa
Depends on:
Blocks: 255301
  Show dependency treegraph
 
Reported: 2021-04-19 05:25 UTC by bourne.identity@hotmail.com
Modified: 2021-04-25 15:20 UTC (History)
7 users (show)

See Also:
koobs: maintainer-feedback? (kib)
madpilot: merge-quarterly+


Attachments
core.txt (71.08 KB, text/plain)
2021-04-19 15:04 UTC, Daniel Tameling
no flags Details
vboxvfs patch (1.04 KB, patch)
2021-04-21 23:19 UTC, Guido Falsi
no flags Details | Diff
Better patch (1.44 KB, patch)
2021-04-21 23:47 UTC, Guido Falsi
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bourne.identity@hotmail.com 2021-04-19 05:25:49 UTC
Hi,

I am using Manjaro Linux as VirtualBox (6.1.18) host and FreeBSD 13.0 RELEASE as a guest. The guest has virtualbox-ose-additions (6.1.18) installed.

Since the version of VirtualBox in the host and the version of virtualbox-ose-additions in the guest is the same, I thought getting VirtualBox shared folders to work would be a breeze. I was wrong.

Upon using mount_vboxsf to mount a VirtualBox shared folder, I got a FATAL error message the first couple of times. After that, using mount_vboxsf simply reboots the system.

Shared clipboard too does not work between host and guest.


Thanks for any solutions,
Manish Jain
Comment 1 Imran Iqbal 2021-04-19 07:30:23 UTC
I have the same problem when using the box provided by the `chef/bento` project:

* https://app.vagrantup.com/bento/boxes/freebsd-13.0

That uses the `virtualbox-ose-additions-nox11` package (6.1.18), so I also attempted after removing that and installing the `virtualbox-ose-additions-nox11-legacy` package (5.2.44_3) instead.  Unfortunately, that hasn't made a difference.

To be clear, shared folders work fine with the previous releases, i.e.

* https://app.vagrantup.com/bento/boxes/freebsd-12.2
* https://app.vagrantup.com/bento/boxes/freebsd-11.4

I did use these before the update to 6.1.18, however.
Comment 2 Li-Wen Hsu freebsd_committer 2021-04-19 07:36:21 UTC
It's unfortunately that the virtualbox-ose-additions and its shared folder feature is developed by the FreeBSD community, and the status is still experimental.  We hope that more collaboration and help from the upstream VirtualBox project on the FreeBSD support.

In the mean time, can you:

- Share the error message you see?
- As a workaround, a local NFS for the file sharing should be reliable.

Also help to inform the upstream that there is a need of supporting FreeBSD guest and encourage they put more attentions on this.
Comment 3 Daniel Tameling 2021-04-19 15:03:04 UTC
I observed the same problem with a Windows 10 host. It works with 12.2 but crashes consistently with 13.0. I managed to get a crash dump, and the panic is caused by a page fault in kernel mode:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read instruction, page not present
instruction pointer     = 0x20:0x0
stack pointer           = 0x0:0xfffffe009db5e688
frame pointer           = 0x0:0xfffffe009db5e6e0
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 926 (mount_vboxvfs)
trap number             = 12
panic: page fault

The backtrace points to vn_lock:

#7  0xffffffff8108a83d in trap (frame=0xfffffe009db5e5c0)
    at /usr/src/sys/amd64/amd64/trap.c:398
#8  <signal handler called>
#9  0x0000000000000000 in ?? ()
#10 0xffffffff80cfc1b8 in VOP_LOCK1 (vp=0xfffff80070b687a0, flags=525312, 
    file=0xffffffff8299449d "/wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/src/VBox/Additions/freebsd/vboxvfs/vboxvfs_vnops.c", line=252) at ./vnode_if.h:1127
#11 _vn_lock (vp=0xfffff80070b687a0, flags=525312, 
    file=0xffffffff8299449d "/wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-6.1.18/src/VBox/Additions/freebsd/vboxvfs/vboxvfs_vnops.c", line=252) at /usr/src/sys/kern/vfs_vnops.c:1742

The corresponding code seems to be this:

/* Get a new vnode and associate it with our node. */
error = getnewvnode("vboxfs", mp, &vboxfs_vnodeops, &vp);
if (error != 0)
	goto unlock;
MPASS(vp != NULL);

/* lkflag is ignored, the lock is exclusive */
(void) vn_lock(vp, lkflag | LK_RETRY);
Comment 4 Daniel Tameling 2021-04-19 15:04:18 UTC
Created attachment 224255 [details]
core.txt
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2021-04-21 04:51:37 UTC
^Triage: Request feedback from kib@ who may be able to shed light.
Comment 6 Guido Falsi freebsd_committer 2021-04-21 22:36:26 UTC
(In reply to Daniel Tameling from comment #3)

Frame 9 shows a NULL (0x0), so, at risk of stating the obvious, this looks like a NULL pointer dereference.

I've looked around base sources just in case I could spot something change. I did not find anything obvious.

I do have a sensation (nothing objective) commit 848f8effdd69 [1] could be related, but I can't say I have an understanding of this code.

I'm still trying to understand what is going on.



[1] https://cgit.freebsd.org/src/commit/?id=848f8effdd69456368366a6bbdba322d0341c98e
Comment 7 Guido Falsi freebsd_committer 2021-04-21 23:19:27 UTC
Created attachment 224342 [details]
vboxvfs patch

Please disregard my comment #6

I think I found the problem, I'm attaching an untested patch. I'm going to test it tomorrow myself.

I'm reasonably sure problem is caused by base commit 6fa079fc3f5e (svn r355790) [1]

There a VFS_VOP_VECTOR_REGISTER() call is performed on the vnodeops struct. I'm not sure what it does, but it missing could explain why a null function pointer ends up being called.

If anyone wants to test, and report back they are welcome, but please note that I have not even tried compiling it for now.


[1] https://cgit.freebsd.org/src/commit/?id=6fa079fc3f5e7e120f166420c6f0c60f701ba9ae
Comment 8 Guido Falsi freebsd_committer 2021-04-21 23:47:17 UTC
Created attachment 224343 [details]
Better patch

New patch, this one includes #if to make it compile also on older FreeBSD versions missing VFS_VOP_VECTOR_REGISTER

Please note that we don't have a __FreeBSD_version bump for this very change, but there is one that happened on the same day, so I picked that.
Comment 9 commit-hook freebsd_committer 2021-04-22 08:20:16 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=8a311de0cb804d8b135413884b4fb336d287ad5a

commit 8a311de0cb804d8b135413884b4fb336d287ad5a
Author:     Guido Falsi <madpilot@FreeBSD.org>
AuthorDate: 2021-04-22 08:15:53 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2021-04-22 08:15:53 +0000

    emulators/virtualbox-ose-additions: Fix vboxvfs panic

    Fix panic on mount when trying to use vbox VFS after
    base r355790 (or git commit hash 6fa079fc3f5e).

    PR:             255208
    MFH:            2021Q2

 emulators/virtualbox-ose-additions/Makefile                          | 1 +
 .../files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c  | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)
Comment 10 commit-hook freebsd_committer 2021-04-22 08:21:17 UTC
A commit in branch 2021Q2 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=fd679460e9c056f582bb858031ed723f6384e701

commit fd679460e9c056f582bb858031ed723f6384e701
Author:     Guido Falsi <madpilot@FreeBSD.org>
AuthorDate: 2021-04-22 08:15:53 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2021-04-22 08:20:39 +0000

    emulators/virtualbox-ose-additions: Fix vboxvfs panic

    Fix panic on mount when trying to use vbox VFS after
    base r355790 (or git commit hash 6fa079fc3f5e).

    PR:             255208
    MFH:            2021Q2
    (cherry picked from commit 8a311de0cb804d8b135413884b4fb336d287ad5a)

 emulators/virtualbox-ose-additions/Makefile                          | 1 +
 .../files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c  | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)
Comment 11 Guido Falsi freebsd_committer 2021-04-22 08:26:11 UTC
After successful testing I committed my patch.

If anyone has further issues please file a new bug report.
Comment 12 Graham Perrin 2021-04-22 08:34:59 UTC
(In reply to Guido Falsi from comment #11)

Thank you! For this and all the other work, much sooner than I expected. 

----

(In reply to bourne.identity@hotmail.com from comment #0)

> … Shared clipboard …

Please see bug 254266 

* in particular, bug 254266 comment 2 

– and the possibility of 254266 being a duplicate of an earlier bug.
Comment 13 bourne.identity@hotmail.com 2021-04-22 09:26:11 UTC
Thanks all for the great work, done in record time too. I still have a question though - will the latest patch also fix the other problem: shared clipboard does not work ?
Comment 14 Guido Falsi freebsd_committer 2021-04-22 10:29:59 UTC
(In reply to bourne.identity@hotmail.com from comment #13)


> Thanks all for the great work, done in record time too. I still have a question > though - will the latest patch also fix the other problem: shared clipboard does > not work ?

No, As far as I can see there is no relation.

I have not been experiencing that issue, and I don't know what could be causing it. Contrary to this problem I have absolutely no clue where to look at to fix that since I don't know how X11 clipboards work.

I;m using VBoxSVGA driver on all my machines though, and really don't know what the point is of using VMSVGA, which looks like having less features.

My personal opinion is that the virtualbox default suggestion of using VMSVGA is misguided.
Comment 15 Guido Falsi freebsd_committer 2021-04-22 10:46:23 UTC
(In reply to Guido Falsi from comment #14)

> My personal opinion is that the virtualbox default suggestion of using VMSVGA is > misguided.

I'll make myself clearer: If you're using guest additions 6.1 there is no reason not to use VBoxSVGA.

I'll post a comment explaining this on the other bug too.
Comment 16 Helge Oldach 2021-04-22 12:42:52 UTC
Quite odd this has been opened only a few days ago. PR 253934 had already been raised 6 weeks ago and contains a proposed (not fully correct) but working solution already...
Comment 17 Guido Falsi freebsd_committer 2021-04-22 13:03:13 UTC
(In reply to Helge Oldach from comment #16)

I was not aware of bug #253934

Anyway it's now fixed, I'm going to close the other one too.
Comment 18 bourne.identity@hotmail.com 2021-04-23 12:07:47 UTC
Hi Guido Falsi/others,

The shared clipboard simply does not work. I am using VMSVGA as the graphics controller, and my host's VirtualBox complains of Invalid Settings if I try to switch to VBoxSVGA.

Should I file another PR for this ?

Please note my vm is dual-boot Linux+FreeBSD. When I boot into Linux, the shared clipboard works flawlessly. But FreeBSD does not - so this is a FreeBSD-specific problem.


Thanks,
Manish Jain
Comment 19 Helge Oldach 2021-04-23 12:21:08 UTC
(In reply to bourne.identity@hotmail.com from comment #18)
Quite obviously this is a different subject, so it would be a new PR.

The VirtualBox suggestion to use VMSVGA is indeed misguided, as stated by Guido already. VboxSVGA works fine for me, including shared clipboard. You may perhaps facing a configuration issue?
Comment 20 Guido Falsi freebsd_committer 2021-04-23 13:13:12 UTC
(In reply to bourne.identity@hotmail.com from comment #18)

> The shared clipboard simply does not work. I am using VMSVGA as the graphics
> controller, and my host's VirtualBox complains of Invalid Settings if I try to 
> switch to VBoxSVGA.

This is two separate things.

First about the "invalid settings"

The "invalid settings" error is a generic one, the graphics setting we are talking aboutsetting is not actually invalid, and the advice can be ignored I don't know why virtualbox has such a scary warning about this, because, if you install additions inside the virtual machine, the correct driver ALWAYS IS VBoxSVGA, for any OS.

SO if both your guests have additions 6.1. installed please disregard the "invalid settings warning" and just use VBoxSVGA, this has anyway advantages.


About the validity of the issue when using VMSVGA, I'm not stating or implying that your issue is invalid, and that there is no bug. Unluckily, when I noticed this issue (crash with vboxvfs) I had a suspect of what the cause could be and where to look at. Regarding the clipboard issue I really have no clue, and the fact that I have zero Xorg programming experience does not help. Starting with no clue like this even if I started looking at this it would take time.


So, if you want a functional VM fast (as in here and now) you can just use VBoxSVGA, install additions in the guest (clipboard would not work without additions anyway) and you will get all the functionality, without any issue. The warning for this setting IS bogus.

If you really don't want to use VBoxSVGA (or even test it) your only option will be waiting for someone to find a fix, or fixing it yourself.


> Should I file another PR for this ?

In general replying to closed bug reports is a problem, not for any ideological issue, but because comments have an high chance to not be noticed. So in general it's better to file a new issue than piggy backing an existing one.

Anyway for the virtualbox guest clipboard there is already an issue opened at bug #254266 so this discussion should be held there.

> Please note my vm is dual-boot Linux+FreeBSD. When I boot into Linux, the 
> shared clipboard works flawlessly. But FreeBSD does not - so this is a 
> FreeBSD-specific problem.

As stated above this makes no difference, linux guests with additions work perfect with VBoxSVGA.