On Sun 27-08-17 11:05:34, Waiman Long wrote:
> On 08/26/2017 12:18 PM, Linus Torvalds wrote:
> > On Fri, Aug 25, 2017 at 11:56 PM, Wangkai (Kevin,C)
> > <wangkai86@xxxxxxxxxx> wrote:
> >> but I am worried, if there are programs create,delete many temporary files and unique,
> >> the negative dentries will keep growing.
> > The thing is, this has nothing to do with unlink.
> >
> > The *easiest* way to generate negative dentries is in fact to never
> > create any files at all: just look up millions of non-existent names.
> >
> > IOW, just something like this
> >
> > #include <stdio.h>
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <unistd.h>
> >
> > int main()
> > {
> > int i;
> > for (i = 0; i < 10000000; i++) {
> > char name[20];
> > struct stat st;
> >
> > snprintf(name, sizeof(name), "n:%d", i);
> > stat(name, &st);
> > }
> > return 0;
> > }
> >
> > is a much easier and faster way to create negative dentries.
> >
> > And yes, it's entirely possible that we could/should have some way to
> > balance negative dentries against positive ones, but on the whole this
> > has not really come up as a huge problem.
>
> 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.
> 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?
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
