lkml.org 
[lkml]   [2015]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount root fs
    2015-01-21, 21:28:33 +0000, Al Viro wrote:
    > On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
    > > ok case (putname commented out):
    > >
    > > user_path_at_empty lookup usr flags 0x0
    > > path_lookupat: calling path_init 'usr' flags=40
    > > path_init: link_path_walk() returned 0
    > > path_lookupat: path_init 'usr' flags=40[50] returned 0
    > > walk_component: lookup_fast() returned 1
    > > walk_component: lookup_slow() returned 0
    > > walk_component: inode= (null), negative=1
    > > do_path_lookup(usr, 0x10)
    > > path_lookupat: calling path_init 'usr' flags=50
    > > path_init: link_path_walk() returned 0
    > > path_lookupat: path_init 'usr' flags=50[50] returned 0
    > > mkdir[c74012a0,/usr] => 0
    > > user_path_at_empty lookup usr flags 0x1
    > > path_lookupat: calling path_init 'usr' flags=41
    > > path_init: link_path_walk() returned 0
    > > path_lookupat: path_init 'usr' flags=41[51] returned 0
    > > walk_component: inode=c74004a0, negative=0
    > > user_path_at_empty lookup usr flags 0x1
    > > path_lookupat: calling path_init 'usr' flags=41
    > > path_init: link_path_walk() returned 0
    > > path_lookupat: path_init 'usr' flags=41[51] returned 0
    > >
    > > failing case:
    > >
    > > path_lookupat: calling path_init 'usr' flags=40
    > > path_init: link_path_walk() returned 0
    > > path_lookupat: path_init 'usr' flags=40[50] returned 0
    > > walk_component: lookup_fast() returned 1
    > > walk_component: lookup_slow() returned 0
    > > walk_component: inode= (null), negative=1
    > > do_path_lookup(usr, 0x10)
    > > path_lookupat: calling path_init 'usr' flags=50
    > > path_init: link_path_walk() returned 0
    > > path_lookupat: path_init 'usr' flags=50[50] returned 0
    > > mkdir[c74012a0,/kkk] => 0 <==== SIC!
    >
    > Cute. 'k' being 0x6b, aka POISON_FREE... OK, the next question is what's
    > been freed under us - I don't believe that it's dentry itself...
    > Oh, fuck. OK, I see what happens. Look at kern_path_create(); it does
    > LOOKUP_PARENT walk, leaving nd->last pointing to the last component of
    > the *COPY* of the name it's just created, walked and freed.
    >
    > OK... Fortunately, struct nameidata is completely opaque outside of fs/namei.c,
    > so we only need to care about a couple of codepaths.
    >
    > Folks, could you check if the following on top of linux-next fixes the problem?

    Yes, it works.


    --
    Sabrina


    \
     
     \ /
      Last update: 2015-01-21 23:01    [W:3.068 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site