Dominique Martinet wrote on Fri, Jul 31, 2015 at 02:28:10PM +0200:
> Unfortunately can't seem to get much more out of it, nd->path is borked
> by the time gdb gets here:
> (gdb) p nd->path
> $1 = {mnt = 0x6f666e69000064, dentry = 0x7379656b64616564}
Looks like gdb is just messing up here. Looking at the value from nd on
the stack (it's in do_filp_open's), nd->path is perfectly valid as
expected -- and has no type:
(gdb) p/x ((struct dentry*)0xffff88042c1eb800)->d_flags
$7 = 0x8088
So somewhere between the check in walk_component:
if (!inode || d_is_negative(path->dentry))
and the d_can_lookup, the entry that wasn't a miss became a miss...
Any hint in how we could tell the "something" clearing it that we use
it? I'm really not familiar with how entries are selected for
deletion...
> Looking at other values around:
> - next->dentry seems to be the last dir (need to rename directories in
> my test to check, bad idea to name them all the same)
> - name is the name of the file that does exist
Doesn't matter much anymore, but changed my directory structures and
caught a few breaks to see more values, it can fail earlier than on last
file.
link_path_walk is probably called with the full d/d2/d3/d4/file path and
cwd entry.
Well that's as far as I'm going to get today, further clues on how to
proceed welcome!
--
Dominique
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
