On 08/31/2017 03:53 AM, Jan Kara wrote: > On Sun 27-08-17 11:05:34, Waiman Long wrote: >> >> It is certainly true that the current scheme of unlimited negative >> dentry creation is not a problem under most cases. However, there are >> scenarios where it can be a problem. >> >> A customer discovered the negative dentry issue because of a bug in >> their application code. They fixed their code to solve the problem. >> However, they wondered if this could be used as one vector of a DoS >> attack on a Linux system by having a rogue program generate massive >> number of negative dentries continuously. It is the thought of this >> malicious use of the negative dentry behavior that prompted me to create >> and send out a patch to limit the number of negative dentries allowable >> in a system. > Well, and how is this fundamentally different from a user consuming > resources by other means (positive dentries, inode cache, page cache, anon > memory etc.)? Sure you can force slab reclaim to work hard but you have > many other ways how a local user can do that. So if you can demonstrate > that it is too easy to DoS a system in some way, we can talk about > mitigating the attack. But just the ability of making the system busy does > not seem serious to me. Positive dentries are limited by the total number of files in the file system. Negative dentries, on the other hand, have no such limit. There are ways to limit other resource usages such as limiting memory usage of a user by memory cgroup, filesystem quota for amount of disk space or number of files created or owned, etc. However, I am not aware of any control mechanism that can limit the number negative dentries generated by a given user. That makes negative dentries somewhat different from the other resource types that you are talking about. >> Besides, Kevin had shown that keeping the dentry cache from growing too >> big was good for file lookup performance too. > Well, that rather speaks for better data structure for dentry lookup (e.g. > growing hash tables) rather than for limiting negative dentries? I can > imagine there are workloads which would benefit from that as well? Current dentry lookup is through a hash table. The lookup performance will depend on the number of hashed slots as well as the number of entries queued in each slot. So in general, lookup performance deteriorates the more entries you put into a given slot. That is true no matter how many slots you have allocated. Cheers, Longman
