[01:37:18] --- Simon Wilkinson has become available
[06:47:37] --- ballbery has become available
[10:42:26] --- Simon Wilkinson has left
[12:50:46] --- Simon Wilkinson has become available
[14:32:34] --- Simon Wilkinson has left
[16:07:36] --- jhutz@jis.mit.edu/owl has become available
[18:56:14] <andersk> Okay I have a crash running with fd 9 pointing to a “deleted” /afs/athena.mit.edu/contrib/scripts.
[20:04:15] <andersk> I don’t see anything obviously wrong with the vfsmount.  The dentry is unhashed (d_hash = {.next = 0, .pprev = 0}), but I’m not seeing why.
[20:16:59] --- ballbery has left
[20:17:00] --- ballbery has become available
[20:23:25] <andersk> I found the dentry named "scripts" inside /afs/athena.mit.edu/contrib’s d_subdirs chain.  Is that a fakestat thing?
[20:28:47] <jhutz@jis.mit.edu/owl> Are you talking to yourself?
[20:29:49] <kaduk@mit.edu/barnowl> never
[20:30:06] <andersk> I dunno, I was hoping deason or someone will show up and have a magical insight.  (This is a continuation of our conversation from Tuesday.)
[20:32:20] <jhutz@jis.mit.edu/owl> Yeah, I just found that.  Apparently my (still ancient) barnowl has not
been auto-subscribing to this room in ~forever.  I'll have to track down
why, if it still happens after I upgrade.
[20:37:45] <jhutz@jis.mit.edu/owl> Not necessarily, and in fact, not at all, if you're not running
fakestat-all (without that, fakestat only applies to other-cell mounts).
Do the two dentries refer to the same inode?  If not, do the inodes
refer to the same vnode?
[20:38:08] <andersk> Two dentries refer to the same inode.
[20:38:55] <andersk> Apparently we are running -fakestat-all.
[20:39:02] <jhutz@jis.mit.edu/owl> Well, that's not good; it violates an invariant (directories may not have
multiple aliases).  Though one of them being unhashed may make it OK.
[20:39:44] <andersk> Alright, except that the one I get when I look up the path is still the unhashed one.
[20:39:57] <jhutz@jis.mit.edu/owl> Oh.  Hm.  Um.
[20:42:18] <jhutz@jis.mit.edu/owl> Oh, hm.  So, walking /afs/athena.mit.edu/contrib's d_subdirs chain looking
for a "scripts" dentry finds only one result, and it is different than the
one you get by looking up "scripts" in that directory?
[20:50:18] <andersk> In fact, yeah, there are two "scripts" dentries in the chain.  The second one is the one you get by looking up "scripts", and is unhashed.
[20:50:28] <jhutz@jis.mit.edu/owl> Does it have a valid d_parent?
[20:50:54] <jhutz@jis.mit.edu/owl> It should, and it's still around because processes like yours have refs.
[20:51:44] <andersk> They both have the same d_parent, and it seems valid.
[20:52:06] <andersk> (It’s where I got the d_subdirs chain from in the first place, at least.)
[20:52:49] <andersk> AFK for now, but I’ll keep these sessions open in case you have other ideas.
[20:55:16] <jhutz@jis.mit.edu/owl> Huh.  I wonder if Linux is returning an incorrectly-cached lookup result,
or if AFS is screwing this up.  It probably has to be the latter.
[21:07:10] <jhutz@jis.mit.edu/owl> If AFS does the lookup, it should
- map the parent directory inode to a vcache
- do the lookup to get the child vcache
- map the child vcache to an inode
- prune existing aliases of the child inode
- splice the child inode into the parent dentry
- return the resulting dentry
[21:12:16] <jhutz@jis.mit.edu/owl> Hm.  But only unreferenced aliases can actually be pruned, so in this
case, since you have a process which has that open (but something with that
as cwd would also count, as would something with a ref to something below
it), it doesn't get dropped...
[21:23:01] <jhutz@jis.mit.edu/owl> Yeah, I'm confused.