On Thu, 2008-02-21 at 04:38 -0800, Andrew Morton wrote:
>
> > <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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
