On Thu, 2008-02-21 at 04:38 -0800, Andrew Morton wrote:
quoted text
> 
> > <4>[    0.071378]  [do_name+279/440] do_name+0x117/0x1b8
> > <4>[    0.071570]  [write_buffer+34/49] write_buffer+0x22/0x31
> > <4>[    0.071763]  [flush_window+105/184] flush_window+0x69/0xb8
> > <4>[    0.071996]  [unpack_to_rootfs+1585/2238] unpack_to_rootfs+0x631/0x8be
> > <4>[    0.072192]  [trace_hardirqs_on_caller+248/301] ? trace_hardirqs_on_caller+0xf8/0x12d
> > <4>[    0.072440]  [restore_nocheck_notrace+0/16] ? restore_nocheck_notrace+0x0/0x10
> > <4>[    0.072689]  [populate_rootfs+37/270] populate_rootfs+0x25/0x10e
> > <4>[    0.072886]  [alternative_instructions+344/349] ? alternative_instructions+0x158/0x15d
> > <4>[    0.073139]  [start_kernel+840/858] start_kernel+0x348/0x35a
> > <4>[    0.073335]  =======================
> 
> (net-related cc's removed)
> 
> This look like a startup ordering bug in mnt_want_write().

Let me look into it a bit.  Although, it does seem that this stuff is
just calling into the filesystem code too early.  The mnt_writers[]
spinlocks are init'd with a:

	fs_initcall(init_mnt_writers);

and populate_rootfs() is supposed to happen in a rootfs_initcall() so
I'm a bit confused how it happened in this order.

-- Dave

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/