linux-kernel - Re: [PATCH v4 0/6] fs/dcache: Limit # of negative dentries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Oct 2017 15:54:39 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Waiman Long <longman@...hat.com>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Ingo Molnar <mingo@...nel.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Larry Woodman <lwoodman@...hat.com>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        "Wangkai (Kevin C)" <wangkai86@...wei.com>
Subject: Re: [PATCH v4 0/6] fs/dcache: Limit # of negative dentries

On Mon, 18 Sep 2017 14:20:28 -0400 Waiman Long <longman@...hat.com> wrote:

> A rogue application can potentially create a large number of negative
> dentries in the system consuming most of the memory available even if
> memory controller is enabled to limit memory usage. This can impact
> performance of other applications running on the system.

It does seem that under these circumstances it is pretty silly of us to
reclaim useful things in order to instantiate zillions of -ve dentries.

Dentries are subject to kmemcg handling.  Does this not help avoid
"impacting performance of other applications"?

> We have customers seeing soft lockup and unresponsive system when
> tearing down a container because of the large number of negative
> dentries accumulated during its up time that had to be cleaned up at
> exit time when the container's filesystem was unmounted. So we need
> to do something about it.

It's a somewhat separate issue, but maybe we're missing a cond_resched
somewhere?  Seeing such a softlockup's output would help.