Re: [LSF/MM TOPIC] Better handling of negative dentries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2022-03-22 at 16:17 -0400, Colin Walters wrote:
> 
> On Tue, Mar 22, 2022, at 3:19 PM, James Bottomley wrote:
> > Well, firstly what is the exact problem?  People maliciously
> > looking up nonexistent files
> 
> Maybe most people have seen it, but for those who haven't:
> https://bugzilla.redhat.com/show_bug.cgi?id=1571183
> was definitely one of those things that just makes one recoil in
> horror.
> 
> TL;DR NSS used to have code that tried to detect "is this a network
> filesystem" by timing `stat()` calls to nonexistent paths, and this
> massively boated the negative dentry cache and caused all sorts of
> performance problems.
> It was particularly confusing because this would just happen as a
> side effect of e.g. executing `curl https://somewebsite`.
> 
> That code wasn't *intentionally* malicious but...

Right, understood.  That's why I think keeping track of negative
dentries coming back to kill_dentry/retain_dentry is a good way of
detecting something like this, so we can get a signal for "some process
bloating the negative dentry cache" and act on it.  My suspicion is
that if we see the signal we can agressively remove old negative
dentries in this same routine, thus penalizing the problem process for
cleaning the caches.  However, it's a very narrow solution somewhat
decoupled from making the dentry cache a better memory management
citizen.

James





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux