Date: Sat, 29 Sep 2001 11:06:36 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Jonathan Lemon <jlemon@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c Message-ID: <200109291106.aa82996@salmon.maths.tcd.ie> In-Reply-To: Your message of "Fri, 28 Sep 2001 23:00:50 PDT." <200109290600.f8T60o869371@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200109290600.f8T60o869371@freefall.freebsd.org>, Jonathan Lemon wri
tes:
>jlemon 2001/09/28 23:00:50 PDT
> MFC: r.1.28; EVFILT_TIMER.
Cool, but it appears that you haven't dealt with the problem of
timeout() allocating only from the small `callfree' list:
/* Fill in the next free callout structure. */
new = SLIST_FIRST(&callfree);
if (new == NULL)
/* XXX Attempt to malloc first */
panic("timeout table full");
All the other kevent filters seem to be tied to some limited/limitable
resource (processes, file descriptors, signals) so creating an
arbitrary number of them is not possible. With EVFILT_TIMER, there
is no such limit, so any user can trivially run the system out of
callouts (ncallouts is typically ~2000). Using the callout_*
interface instead helps a lot (I sent you patches for this some
time ago), but any user can still run the system out of kernel
memory and fill the callout wheel with millions of timers.
I really dislike seeing the addition of new ways for any local user
to crash the system, especially in RELENG_4. Even an arbitrary
limit set by a kern.maxkqtimersperproc sysctl, together with using
the callout_* interface, would make this a non-issue. Maybe
EVFILT_TIMER should be disabled in RELENG_4 for now until this
issue is resolved?
Ian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200109291106.aa82996>