svn commit: r256850 - in head: bin/sh etc lib/libc/sys lib/libutil usr.bin/limits usr.bin/procstat

[Jilles Tjoelker]

On Wed, Oct 30, 2013 at 02:01:57PM +0100, Stefan Neudorf wrote:
> Konstantin Belousov <kib at FreeBSD.org> writes:

> > Author: kib
> > Date: Mon Oct 21 16:46:12 2013
> > New Revision: 256850
> > URL: http://svnweb.freebsd.org/changeset/base/256850

> > Log:
> >   Add a resource limit for the total number of kqueues available to the
> >   user.  Kqueue now saves the ucred of the allocating thread, to
> >   correctly decrement the counter on close.

> >   Under some specific and not real-world use scenario for kqueue, it is
> >   possible for the kqueues to consume memory proportional to the square
> >   of the number of the filedescriptors available to the process.  Limit
> >   allows administrator to prevent the abuse.

> >   This is kernel-mode side of the change, with the user-mode enabling
> >   commit following.

> >   Reported and tested by:	pho
> >   Discussed with:	jmg
> >   Sponsored by:	The FreeBSD Foundation
> >   MFC after:	2 weeks

> > Modified:
> >   head/bin/sh/miscbltin.c
> >   head/etc/login.conf
> >   head/lib/libc/sys/getrlimit.2
> >   head/lib/libutil/login_class.3
> >   head/lib/libutil/login_class.c
> >   head/usr.bin/limits/limits.c
> >   head/usr.bin/procstat/procstat_rlimit.c

> kqueues limit isn't documented in sh(1) and limits(1) manpages.

I can do this in the next few days.

> > Modified: head/bin/sh/miscbltin.c
> > ==============================================================================
> > --- head/bin/sh/miscbltin.c	Mon Oct 21 16:44:53 2013	(r256849)
> > +++ head/bin/sh/miscbltin.c	Mon Oct 21 16:46:12 2013	(r256850)
> > @@ -405,6 +405,9 @@ static const struct limits limits[] = {
> >  #ifdef RLIMIT_NPTS
> >  	{ "pseudo-terminals",	(char *)0,	RLIMIT_NPTS,	   1, 'p' },
> >  #endif
> > +#ifdef RLIMIT_KQUEUES
> > +	{ "kqueues",		(char *)0,	RLIMIT_KQUEUES,	   1, 'k' },
> > +#endif
> >  	{ (char *) 0,		(char *)0,	0,		   0, '\0' }
> >  };
> >  

> I've submitted a patch to add ulimit -k (kqueue) to zsh but the reviewer
> asked me to rename -k to -K to avoid conflict with ulimit -k (posixlocks)
> from DragonFly. Do you anticipate FreeBSD never adds RLIMIT_POSIXLOCKS
> support or would use incompatible option switch?

> http://www.zsh.org/mla/workers/2013/msg00984.html
> http://gitweb.dragonflybsd.org/dragonfly.git?a=search&h=HEAD&st=commit&s=posixlocks

I think dragonfly has invented its own name here. The usual name for
RLIMIT_POSIXLOCKS (Linux and Solaris) is RLIMIT_LOCKS and ulimit has it
under -x (bash) or -L (ksh93). It seems more appropriate for FreeBSD to
follow one of those. (On the other hand, dash ulimit has it on -w.)

Generally, the namespace for ulimit letters is very small so
inconsistencies between shells and implementations are to be expected.
Also, various shell implementations appear to have stopped caring to add
new rlimits to their ulimit builtin.

zsh's -N <numeric resource> option avoids the need to modify the shell
for new rlimits, but is probably too cryptic to use other than via
limits -e.

> > Modified: head/usr.bin/limits/limits.c
> > ==============================================================================
> > --- head/usr.bin/limits/limits.c	Mon Oct 21 16:44:53 2013	(r256849)
> > +++ head/usr.bin/limits/limits.c	Mon Oct 21 16:46:12 2013	(r256850)

> This adds limits -e support only for sh, csh, tcsh. What about other
> shells that already support sbsize and swapuse extensions?

This can be done later; the kqueue rlimit need not be gated on it.

-- 
Jilles Tjoelker