Date:	Tue, 16 May 2000 23:18:31 -0400 (EDT)
From: Alexander Viro <viro@math.psu.edu>
To: linux-fsdevel@vger.rutgers.edu
Subject: [RFC][Attention] dcache threading - interface changes.

	Yup, it's actually starting to happen. Changes to come:
a) ->d_count becoming atomic.
b) ->d_delete() becoming non-blocking.
c) unsafe dget() calls being protected by spinlock (unsafe == ones where
we don't keep at least one reference to the thing).
d) same spinlock covering the beginning of dput() - up to the point where
dentry is excluded from the lists or left alone.
e) code that walks ->d_alias/->i_dentry or ->d_subdirs/->d_child moves to
VFS proper. Each of these pieces should go under the spinlock and end with
dget(). This code should skip unhashed dentries.
f) _all_ places that check for ->d_count should be either exterminated or
get an attempt to unhash in front of them. The only valid checks being
"are we the sole owners of dentry".
g) manipulation with lists (see above + d_lru/d_hash) are protected by the
same spinlock.

	Potential problems:
1) 3rd-party code using the lists. Folks, if your code does that - TELL
ABOUT THAT HERE.
2) 3rd-party code with blocking ->d_delete(). Ditto. Normally it can be
worked around.
3) blind tests for ->d_count. Very bad, usually it means racy code. Again,
show up and tell.
	Existing problems:
1) devfs_open() - illegal test for ->d_count. Actually it's a bug even in
the current tree - dentry may be held without ->open(), so we are risking
to miss the first (and thus - all subsequent) ->open(). Richard, what were
you actually trying to do here?
2) nfs_rename() and nfs_unlink() problems - will be dealt with.
3) very murky code in fs/coda/cache.c - I'm not sure that it works right
now, but I _am_ sure that it will take tweaking for threaded dcache.
Peter, could you describe what it is _supposed_ to do? What it _does_
looks rather strange, so I'ld prefer to hear what you want from the thing.
4) fs/nfsd/nfsfh.c. 'nuff said.
5) fs/umsdos/check.c - fix exists (rm(1)).
6) interesting code in ncp_readdir() - will be dealt with.

	The bottom line: if you are maintaining an out-of-tree filesystem
that uses dcache in non-trivial way - either post on fsdevel or get in
touch with me in any other way ASAP. If you don't - well, you have 
yourself to blame when your code will break. This change is _really_
needed; it had been requested many times; 2.3 is an unstable branch;
you are warned.