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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
