On Wed, Apr 03, 2019 at 06:19:21PM +0100, Al Viro wrote: > On Wed, Apr 03, 2019 at 06:08:11PM +0100, Al Viro wrote: > > > Oh, *brilliant* > > > > Let's do d_invalidate() on random dentries and hope they go away. > > With convoluted and brittle logics for deciding which ones to > > spare, which is actually wrong. This will pick mountpoints > > and tear them out, to start with. > > > > NAKed-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > > > And this is a NAK for the entire approach; if it has a positive refcount, > > LEAVE IT ALONE. Period. Don't play this kind of games, they are wrong. > > d_invalidate() is not something that can be done to an arbitrary dentry. > > PS: "try to evict what can be evicted out of this set" can be done, but > you want something like > start with empty list > go through your array of references > grab dentry->d_lock > if dentry->d_lockref.count is not zero > unlock and continue > if dentry->d_flags & DCACHE_SHRINK_LIST > ditto, it's not for us to play with > if (dentry->d_flags & DCACHE_LRU_LIST) > d_lru_del(dentry); > d_shrink_add(dentry, &list); > unlock > > on the collection phase and > if the list is not empty by the end of that loop > shrink_dentry_list(&list); > on the disposal. Note, BTW, that your constructor is wrong - all it really needs to do is spin_lock_init() and setting ->d_lockref.count same as lockref_mark_dead() does, to match the state of dentries being torn down. __d_alloc() is not holding ->d_lock, since the object is not visible to anybody else yet; with your changes it *is* visible. However, if the assignment to ->d_lockref.count in __d_alloc() is guaranteed to be non-zero to non-zero, the above should be safe.
