Date: Tue, 16 May 2000 23:18:31 -0400 (EDT) From: Alexander Viro <email@example.com> To: firstname.lastname@example.org 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.