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]

Message-ID: <41d8db7e-4538-aaaf-6d65-574b5c0ffd7a@redhat.com>
Date:   Wed, 11 Oct 2017 16:47:05 -0400
From:   Waiman Long <longman@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
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 10/10/2017 06:54 PM, Andrew Morton wrote:
> 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.

I am talking about a misbehaving program due to bug or an intentional
rogue program.

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

AFAIK, the dentry kmem_cache isn't memcg aware. So memcg can't really
constrain the dentry allocation.

>> 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.
>
I don't have a console log. I got this information indirectly via some
of our customer-facing engineers.

Cheers,
Longman