Guest kernel panic when listing contents of a shared folder with Linux 2.6.32 => Fixed in SVN/3.1.4

log file

you beat me to it. im seeing the same thing, linux host - linux guest. listing contents of shared folder = instant kernel oops. since i cannot copy the log, i made a screenshot.

Confirmed. Should be fixed in r25637. You can apply the fix manually to your guest and recompile the guest kernel modules with /etc/init.d/vboxadd setup. After that, reboot your guest and you should now be able to access shared folders. The fix will be contained in the next maintenance release.

It doesn't appear that the fixes in svn are completely successful. On doing an "ls" in a win7 shared folder I get a kernel traceback prompt and the following in the message logs in a Debian/sid guest with kernel 2.6.32.

[ 428.455635] ------------[ cut here ]------------ [ 428.455648] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/fs/fs-writeback.c:1112 mark_inode_dirty+0xbe/0x10b() [ 428.455655] Hardware name: VirtualBox [ 428.455660] Modules linked in: vboxvideo drm agpgart vboxvfs vboxguest nls_utf8 isofs udf crc_itu_t ppdev lp sco bridge stp rfcomm bnep l2cap crc16 bluetooth rfkill processor cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats binfmt_misc fuse loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq snd_timer snd_seq_device parport_pc parport snd serio_raw ac pcspkr psmouse i2c_piix4 evdev i2c_core soundcore snd_page_alloc ext3 jbd mbcache ide_gd_mod ohci_hcd ide_cd_mod cdrom ata_generic libata scsi_mod ide_pci_generic floppy ehci_hcd piix pcnet32 mii button usbcore nls_base ide_core thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 428.455714] Pid: 5665, comm: ls Tainted: G W 2.6.32-trunk-686 #1 [ 428.455720] Call Trace: [ 428.455732] [<c1030ba1>] ? warn_slowpath_common+0x5e/0x8a [ 428.455739] [<c1030bd7>] ? warn_slowpath_null+0xa/0xc [ 428.455745] [<c10c7ad2>] ? mark_inode_dirty+0xbe/0x10b [ 428.455752] [<c10c0433>] ? touch_atime+0xbe/0xd9 [ 428.455757] [<c10bcb2e>] ? vfs_readdir+0x75/0x8c [ 428.455760] [<c10bc888>] ? filldir64+0x0/0xc5 [ 428.455762] [<c10bcbab>] ? sys_getdents64+0x66/0xa5 [ 428.455766] [<c10030fb>] ? sysenter_do_call+0x12/0x28 [ 428.455768] ---[ end trace 484fa1421b53fd0f ]--- [ 428.455770] bdi-<NULL> not registered

Which svn revision are you using and did you rebuild the guest additions from this revision and did you reinstall these guest additions?

I am using 3.1.2r56127 release with Guest Additions rebuilt with the three patches listed in a revision linked from this bug report at http://www.virtualbox.org/changeset/25637 with "/etc/init.d/vboxadd setup". Before I rebuilt the GA with the above patches I was getting consistent oopses with kernel 2.6.32, but now at least the kernel stays running and it's "ls" calls that produce the traces I provided.

please look at http://bugs.gentoo.org/show_bug.cgi?id=298988 and my fix http://bugs.gentoo.org/attachment.cgi?id=214629, i think it properly resolves the problem (modulo the linux version check ;).

A similar fix is already included in VBox 3.1.4 Beta 1 which can be found here. Btw, bdi_init() was introduced with Linux 2.6.24 not with Linux 2.6.0.

I was able to reproduce the problem here but calling bdi_register() and bdi_destroy() was not necessary. Are you sure that calling them is required?

I wonder why you don't call bdi_init() from the module init() function? It initializes a static structure so no

Replying to frank:

A similar fix is already included in VBox 3.1.4 Beta 1

yes i know (if you mean changeset 25637) but it's wrong, the bdi_register and the necessary cleanup code are needed because later VFS (or whatever, i forget now) code will follow some pointer (iirc, bdi->dev) that is NULL unless you also register this structure (i.e., this later call assumes that you have registered it, it doesn't check for NULL pointers).

you can trigger this case after mounting by simply doing an 'ls' in the shared filesystem (at least that's how i ran into it last year and had to do some digging before i figured out that init is not enough, registering is needed as well).

I wonder why you don't call bdi_init() from the module init() function? It initializes a static structure so no [something cut off?]

to be honest, i don't know much about all this VFS/bdi stuff, i just tried to follow what other kernel code (e.g., btrfs, fuse, ubifs) does in this case: they all do the init/register sequence in the fill_super callback, not at module init time. on second thought, they also runtime allocate this bdi structure (one per mount or so), so it's very well possible that vboxfs would have to do the same (as it is now, if you have more than one shared folders and mount them at the same time, this bdi structure will be shared among them, not sure if that's a valid use, better ask on lkml).

Thanks for this explanation. And yes, sharing the same structure between two vboxvfs instances seems to not work, I get guest lookups here. Will try with a dynamically initialized structure.

And regarding your Gentoo bug report: Note that we can't follow every bugtracker system on the planet, so if you really want to get something fixed in VBox itself and not only in VBox-OSE for some Linux distribution, then better add comments here, not in a bugtracker specific to a Linux distribution, ok? ;-)

Replying to frank:

And regarding your Gentoo bug report:

oh, i think you misunderstood my last comment there, it wasn't directed at you guys at all, but rather the gentoo devs who have been sitting on it for a month now (as you can see, i'd fixed this, more or less, even before this bug entry here) and it would have been nice if they had followed up on it. like yourself, i have limited time and energy to track bugs and fixes, so i normally just report it to gentoo and have them handle upstream, except the process breaks down sometimes, sorry about that.

Anyway, thanks again for the help! I adapted the code and tested it with a dynamically allocated structure and now it works as expected. The fix can be found in r26102 and it will be included in the upcoming release 3.1.4. Feedback appreciated.

Replying to frank:

Feedback appreciated.

i tested it on 3.1.2 and it worked fine for me, thanks.