Bug 26214

I did a fresh install of Mageia 7.1 x86_64 on the host, with a new virtualbox
guest on it running Mageia 7.1 i586. This is using release media only, no
updates and the problem is not visible there.

That's using kernel-desktop-5.1.14-1.mga7-1-1.mga7 on the host and
kernel-desktop586-5.1.14-1.mga7-1-1.mga7 in the guest.

I'll experiment with updates tomorrow.

 Well, the vboxsf code is running on the host, so thats 64bit for you :)


But looking on the kernel commit logs...

Does it still work with:

kernel-5.3.13-2.mga7

and break with:

kernel-5.4.2-1.mga7 ?

CC: (none) => tmb

And what comment in dir.c did you refer to ?

(In reply to Thomas Backlund from comment #3)
> And what comment in dir.c did you refer to ?

If you mean this:

/*
 * Note the vboxsf_dir_info objects we are iterating over here
 * are variable sized, so the info pointer may end up being
 * unaligned. This is how we get the data from the host.
 * Since vboxsf is only supported on x86 machines this is not
 * a problem.
 */

then that is not it as x86 means the base arch in the kernel, and that covers both  ix86 and x86_64

Also, please try with virtualbox 6.0.18 in bug 26238

It has official upstream support for kernel 5.5 series

Hello together, after investigating two days I figured something very similar as reported in the bug. 

My setup:
- Windows 10 (1909) Pro with Virtual Box 6.1.10 as host system
- Mageia 7 i585 (32bit) within Virtual Box as guest

I don't have dkms-virtualbox installed, because vboxsf is already provided by the kernel itself, as well as vboxguest and vboxvideo. Using kernel-desktop-5.2.* and kernel-desktop-5.3.* I can access without any problems shared directories from Windows 10 host. Actually I'm using kernel-desktop-5.3.11-1.mga7

Starting with kernel-desktop-5.4.* series files that are copied from guest to host are corrupted and locking into simple textfiles e.g. less /shared/folder/foo.txt is only presented after the hint "may be a binary file. See it anyway?".

I observe the same behaviour with kernel-desktop-5.5.* and kernel-desktop-5.6.14-desktop-2.mga7 I also tried kernel-linus-5.6.14-1.mga7 yesterday. All kernels after 5.3 seems to have that problem. If I'm right vboxsf is released with VirtualBox Shared Folder Driver in place since Linux 5.4-rc7.
But so far I didn't find any reports about problems like that in other distributions or on the LKML.

I can trigger the problem by rebooting my virtual machine and switch from kernel-desktop-5.3.11-1.mga7 to kernel-desktop-5.6.14-desktop-2.mga7 and resolve it the other way round.

I also tried to build 3rdparty modules using dkms-vboxadditions-6.0.20-1mga7 but the build process (dkms build -m vboxadditions -v 6.0.20-1.mga7 -k 5.6.14-desktop-2.mga7 -a i586 --no-clean-kernel) which is normally called from dkms_autoinstaller fails with code 10 when compiling vboxvideo module. I didn't had the time to figure that down....

To sum up: I can observe corrupted files using a kernel above 5.3.* as reported in this bug but my host is a windows and not a linux system. My workaround is so far using a kernel version 5.3 where everything is fine but of cause I'd like to nail this bug down in upper versions.

CC: (none) => s.puch

Has no one an idea what could be root of the cause?
I'm still facing this problem with every kernel version greater kernel-desktop-5.3.*
I just tried kernel-desktop-5.10.6 and kernel-linus-5.10.12 together with virtualbox-guest-addition-6.1.18

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED

Finally fixed in virtualbox-6.1.34-1.5.mga8

...which is Bug 30507 - Update request: virtualbox-6.1.34-1.5.mga8

CC: (none) => fri

Note it's still in testing for now. Should be released as an update soon.

I must have done something wrong. Wanted to confirm it was the vb guest additions
that fixed it and not the kernel (I'd installed both for testing), so reverted the
snapshot and retested. Even with both installed, the problem is still there.

Source RPM: kernel-5.5.4-1.mga7.src.rpm => kernel-5.15.44-1.mga8.src.rpm
Version: 7 => 8
Resolution: OLD => (none)
Status: RESOLVED => REOPENED

I have just tried with host from cauldron x86_64 and a Mageia 8 i586 guest and can confirm the problem.

I am not sure where the content comes from, either memory or the guest filesystem. Data is cached but changes when remounting the shared folder. I once got something containing a command I had just typed in the guest so either from bash memory in the guest or possibly from the bash_history file in the guest too.

I tried looking at the code but nothing obvious.

In the i586 guest, I also tried using VBoxGuestAdditions_6.1.34.iso instead of the rpm package for the additions, with identical results.

Tu be sure this is not a Mageia problem on the guest I tried a Debian i386 guest with Mageia x86_64 host and the result is slightly different but still broken, files contain only 0s.

I however don't have any non Mageia machine to try a different host.

I did a search and found a similar report with x86_64 windows host, x86_64 linux guest is fine but i386 linux guest gets corrupted files

https://forums.virtualbox.org/viewtopic.php?f=6&t=105367

I added some logging some more debugging, the content of the file is whatever is in the kernel buffer in the guest before doing a call to the host, size gets updated based on the number of bytes read but the content doesn't get written.

So the data is random guest memory (at least it's not host memory...).

Logs when reading a 4097 bytes files:

[ 6975.339747] vboxsf_read: requested offset: 0
[ 6975.339846] vboxsf_read: requested buf_len: 4096
[ 6975.339945] hgcm_call_preprocess: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c5000, size = 4096)
[ 6975.340141] 23 31 36 35
[ 6975.340316] hgcm_call_init_call: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c5000, size = 4096)
[ 6975.340589] hgcm_call_copy_back_result: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (dst=0xfe4c5000, size = 4096)
[ 6975.340776] vboxsf_read: err: 0
[ 6975.340859] vboxsf_read: buf_len: 4096
[ 6975.340965] vboxsf_read: 23 31 36 35
[ 6975.341143] vboxsf_read: requested offset: 4096
[ 6975.341244] vboxsf_read: requested buf_len: 4096
[ 6975.341343] hgcm_call_preprocess: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c6000, size = 4096)
[ 6975.341528] 69 6e 73 6d
[ 6975.341600] hgcm_call_init_call: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (buf=0xfe4c6000, size = 4096)
[ 6975.341840] hgcm_call_copy_back_result: VMMDEV_HGCM_PARM_TYPE_LINADDR_KERNEL_OUT (dst=0xfe4c6000, size = 4096)
[ 6975.342026] vboxsf_read: err: 0
[ 6975.342107] vboxsf_read: buf_len: 1
[ 6975.342191] vboxsf_read: 69 6e 73 6d

I also tried running VirtualBox provided binary and the bug is there too, it is not specific to Mageia as host or guest.

I came back to this bug and did a bit more debugging and looked at a dump of the guest memory.

It seems the data is correctly the guest physical address given to the host, which is computed in hgcm_call_init_linaddr using:

  page = virt_to_page(buf);
  dst_pg_lst->pages[i] = page_to_phys(page);

But this is not visible in buf.

I have a large file full of the character '1' (0x31) that I read from the guest.
$ hexdump ~/VirtualBox\ VMs/Shared/foo3.txt 
0000000 3131 3131 3131 3131 3131 3131 3131 3131
*
1000000

Looking for it in the memory dump:
3e328010 0000 0000 0000 0000 0000 0000 0000 0000
*
3e329000 3131 3131 3131 3131 3131 3131 3131 3131
*
3e600000 0000 0000 0000 0000 0000 0000 0000 0000

From the guest logs:

[ 9124.797579] hgcm_call_copy_back_result: page=0x3e4c9000
[ 9124.797639] hgcm_call_copy_back_result: page=0x3e4ca000
[ 9124.797693] hgcm_call_copy_back_result: page=0x3e4cb000
[ 9124.797761] hgcm_call_copy_back_result: page=0x3e4cc000
[ 9124.798023] hgcm_call_copy_back_result: page=0x3e4cd000
...
[ 9124.804713] hgcm_call_copy_back_result: page=0x3e526000
[ 9124.805033] hgcm_call_copy_back_result: page=0x3e527000
[ 9124.805091] hgcm_call_copy_back_result: page=0x3e528000

However from the same logs, the data is just random garbage in buf which is supposed to be at that address...

I'm just bit by this bug.
Host : Mageia 8 64 bits
Guest : Mageia cauldron 32 bits

CC: (none) => yves.brungard_mageia
Version: 8 => Cauldron
Whiteboard: (none) => MGA8TOO

I didn't find any upstream bug report in https://bugzilla.kernel.org