We walk the list of dentries in subdirs on lock invalidation. This can
be a large number so we were trying to back off and give other tasks a
chance to schedule and other processes a chance to grab the parent lock
while we were iterating.
The method for backing off saved our position in the list by getting a
reference on a child dentry. It dropped that reference after resuming
iteration.
But it dropped the reference while holding the parent's lock. This is a
deadlock if the put tries to finally remove the dentry because it's been
unhashed. We saw this deadlock in practice, the crash dump showed us in
the final dentry_kill with the parent locked.
Let's just get rid of this premature optimization entirely. Both memory
pressure and site logistics will tend to keep child lists in parents
reasonably small. A CPU can burn through the locks and list entries for
quite a few entries before anything will notice. We can revisit the hot
spot later it if bubbles to the surface.
Signed-off-by: Zach Brown <zab@versity.com>