Re: 2.6.39-rc5-git2 boot crashs

[Linus Torvalds]

On Fri, Apr 29, 2011 at 7:31 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> It looks like a NULL pointer dereference with offset 4, so at a guess,
> super->s_freeing_list.next is NULL, and it's the "next->prev = entry"
> instruction that faults when inserting into that list.
>
> How/why would s_freeing_list be NULL? I have no idea. But it looks
> like a failed mount, so presumably it was never initialized.

Hmm. super->s_freeing_list is initialized pretty late in
logfs_read_sb(), and any error path _before_ that point will result in
a "goto err1" in logfs_get_sb_device() which will do various iputs
etc. All without that list initialized. That would seem to be the
cause of this, possibly triggered by Al's changes to ->mount from
read_super.

Somebody who knows the code better than me (ie any reasonably
well-educated squirrel) should take another look, though.

Werner, if this is easily repeatable for you, could you test just
moving up the lines that initialize the superblock mutexes and the
s_freeing_list to the top of logfs_read_sb() rather than the end (ie
move the three lines that do

        mutex_init(&super->s_dirop_mutex);
        mutex_init(&super->s_object_alias_mutex);
        INIT_LIST_HEAD(&super->s_freeing_list);

to be before the call to mempool_create(). That way those things will
be initialized much earlier, which is definitely what we want.

Whether that's the only problem and actually fixes it, I won't even
begin to guess, though.

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