lkml.org 
[lkml]   [2008]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.6.25-rc2-mm1 - several bugs and a crash
From
Date

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



\
 
 \ /
  Last update: 2008-02-21 20:39    [W:0.154 / U:1.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site