On Wed, Jul 19, 2017 at 10:42 PM, Waiman Long [off-list ref] wrote:

On 07/19/2017 04:24 PM, Miklos Szeredi wrote:

quoted

On Mon, Jul 17, 2017 at 3:39 PM, Waiman Long [off-list ref] wrote:

quoted

The number of positive dentries is limited by the number of files
in the filesystems. The number of negative dentries, however,
has no limit other than the total amount of memory available in
the system. So a rogue application that generates a lot of negative
dentries can potentially exhaust most of the memory available in the
system impacting performance on other running applications.

To prevent this from happening, the dcache code is now updated to limit
the amount of the negative dentries in the LRU lists that can be kept
as a percentage of total available system memory. The default is 5%
and can be changed by specifying the "neg_dentry_pc=" kernel command
line option.

Signed-off-by: Waiman Long <longman@redhat.com>
---

[...]

quoted

@@ -603,7 +698,13 @@ static struct dentry *dentry_kill(struct dentry *dentry)

        if (!IS_ROOT(dentry)) {
                parent = dentry->d_parent;
-               if (unlikely(!spin_trylock(&parent->d_lock))) {
+               /*
+                * Force the killing of this negative dentry when
+                * DCACHE_KILL_NEGATIVE flag is set.
+                */
+               if (unlikely(dentry->d_flags & DCACHE_KILL_NEGATIVE)) {
+                       spin_lock(&parent->d_lock);

This looks like d_lock ordering problem (should be parent first, child
second).  Why is this needed, anyway?

Yes, that is a bug. I should have used lock_parent() instead.

lock_parent() can release dentry->d_lock, which means it's perfectly
useless for this.

I still feel forcing  free is wrong here.  Why not just block until
the number of negatives goes below the limit (start reclaim if not
already doing so, etc...)?

Thanks,
Miklos