Re: VirtualBox Hangs Pre-Init Due To Ext2FS Fault

[Richard Braun]

On Sat, Jun 27, 2015 at 03:39:58PM +0100, James Clarke wrote:
> I have been suffering a lot from my Hurd system (running in VirtualBox) 
> hanging at startup, just after "Hurd server bootstrap..." but before "INIT: 
> version 2.88 booting".
> 
> I have been able to trace it back to getblk.c:248 (unsigned long 
> addr_per_block = EXT2_ADDR_PER_BLOCK (sblock);) in ext2_getblk. It faults 
> because sblock is NULL.
> 
> I have traced the execution with debugging statements, and what seems to 
> happen is as follows:
> 
> 1. diskfs_remount is called (because root is remounted as rw)
> 2. RPCs are inhibited
> 3. diskfs_reload_global_state is called
> 4. sblock is set to NULL
> 5. While this is happening, ext2_getblk is called
> 
> If you’re lucky, the superblock is read and sblock is set to point to this 
> data before 5 (or at least before it gets to dereferencing sblock). If not, 
> sblock is still NULL and thus a page fault is raised, causing the system to 
> be stuck.
> 
> Does anyone have an idea how this situation could be occurring?

My initial thought would be "how could it not happen ?".

Despite diskfs_remount calling ports_inhibit_class_rpcs, other threads
can very well be running to process previously received messages. There
seems to be no other form of access synchronization such as locks in
diskfs_reload_global_state.

Can you get the call trace leading to ext2_getblk ? I'm not sure about
backtrace(3) in static executables but it might be worth trying.

-- 
Richard Braun