From: Andrew Morton <akpm@linux-foundation.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <gregkh@suse.de>, Willy Tarreau <w@1wt.eu>,
Michael Kerrisk <mtk.manpages@googlemail.com>,
Bron Gondwana <brong@fastmail.fm>
Subject: Re: [patch] drop epoll max_user_instances and rely only on max_user_watches
Date: Thu, 29 Jan 2009 00:57:16 -0800 [thread overview]
Message-ID: <20090129005716.6dd51929.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.1.10.0901282010250.21401@alien.or.mcafeemobile.com>
> Subject: [patch] drop epoll max_user_instances and rely only on max_user_watches
nanonit: please prepare titles in the form "subsystem-id:
what-i-did-to-it", so a suitable name here would be
epoll: drop max_user_instances and rely only on max_user_watches
On Wed, 28 Jan 2009 20:56:07 -0800 (PST) Davide Libenzi <davidel@xmailserver.org> wrote:
> Linus suggested to put limits where the money is, and max_user_watches
> already does that w/out the need of max_user_instances. That has the
> advantage to mitigate the potential DoS while allowing pretty generous
> default behavior.
A reader of this changelog would be wondering what this DoS is.
> Allowing top 4% of low memory (per user) to be allocated in epoll
> watches, we have:
>
> LOMEM MAX_WATCHES (per user)
> 512MB ~178000
> 1GB ~356000
> 2GB ~712000
>
> A box with 512MB of lomem, will meet some challenge in hitting 180K
> watches, socket buffers math teaches us.
> No more max_user_instances limits then.
So the max consumable memory is
number-of-users * max_user_watches * sizeof(whatever)
?
So if enough users gang up (or if one person has access to a lot of
UIDs), there's still a DoS?
I suspect we can live with that.
I assume that because you based all this on all the other patches, you
view it as 2.6.30 material?
> @@ -581,10 +570,6 @@
please use `diff -p'. It helps.
> struct eventpoll *ep;
>
> user = get_current_user();
> - error = -EMFILE;
> - if (unlikely(atomic_read(&user->epoll_devs) >=
> - max_user_instances))
> - goto free_uid;
> error = -ENOMEM;
> ep = kzalloc(sizeof(*ep), GFP_KERNEL);
> if (unlikely(!ep))
> @@ -1141,7 +1126,6 @@
> flags & O_CLOEXEC);
> if (fd < 0)
> ep_free(ep);
> - atomic_inc(&ep->user->epoll_devs);
>
> error_return:
> DNPRINTK(3, (KERN_INFO "[%p] eventpoll: sys_epoll_create(%d) = %d\n",
I hit a reject here (which is actually in epoll_create1()) (and diff -p
might not have told us of this, because of that darned
SYSCALL_DEFINE1() thing we just added) (which broke ctags too).
The code I have is
if (error < 0)
ep_free(ep);
else
atomic_inc(&ep->user->epoll_devs);
so I obviously nuked the `else' as well.
next prev parent reply other threads:[~2009-01-29 8:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-29 4:56 [patch] drop epoll max_user_instances and rely only on max_user_watches Davide Libenzi
2009-01-29 8:42 ` Bron Gondwana
2009-01-29 8:57 ` Andrew Morton [this message]
2009-01-29 10:03 ` Michael Kerrisk
2009-01-29 18:14 ` Greg KH
2009-01-29 18:54 ` Davide Libenzi
2009-02-01 1:26 ` Michael Kerrisk
2009-02-01 1:30 ` Davide Libenzi
2009-02-01 1:43 ` Michael Kerrisk
2009-02-01 1:49 ` Davide Libenzi
2009-01-29 18:46 ` Davide Libenzi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090129005716.6dd51929.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=brong@fastmail.fm \
--cc=davidel@xmailserver.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.