Hello Hillf, On 7/17/22 13:36, Hillf Danton wrote: > On Sun, 17 Jul 2022 11:42:48 +0200 >> I used WARN_ON() instead of BUG_ON(). >> With that, both triggered, first the first one, then the second one. >> Full log is here: >> http://dellerweb.de/testcases/minicom.dcache.crash.6-warn > > Given the first BUG_ON triggered, and dentry at the moment is supposed to > not be alias, see if it is still in lookup with d_lock held. That is the > step before de-unioning d_alias with d_in_lookup_hash. > > On the other hand if only the second one triggered, we should track > DCACHE_DENTRY_KILLED instead in assumption that killed dentry was > used again after releasing d_lock surrounding the firt one. The machine has now been up for 2 days without any issues, while it had pretty much the same load as when it was crashing earlier. So, in summary I'd assume that your patch below fixes the issue. I'm now rebooting the machine with a new kernel, where I just changed if (unlikely(d_in_lookup(dentry))) to if (WARN_ON_ONCE(d_in_lookup(dentry))) in order to see if this really triggered. Anyway, I think your patch is good so far. Would that be the final patch, or should I test some others? Thanks! Helge > > --- a/fs/dcache.c > +++ b/fs/dcache.c > @@ -605,8 +605,12 @@ static void __dentry_kill(struct dentry > spin_unlock(&parent->d_lock); > if (dentry->d_inode) > dentry_unlink_inode(dentry); > - else > + else { > + if (unlikely(d_in_lookup(dentry))) { > + __d_lookup_done(dentry); > + } > spin_unlock(&dentry->d_lock); > + } > this_cpu_dec(nr_dentry); > if (dentry->d_op && dentry->d_op->d_release) > dentry->d_op->d_release(dentry);
