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

[Konstantin Belousov]

On Wed, Oct 30, 2013 at 10:20:52PM +0100, Jilles Tjoelker wrote:
> 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.
Thank you, appreciated.

> 
> > > 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.)
The RLIMIT_LOCKS is for the fcntl(2) locks, right ? It is very strange
for me, and almost misleading, to have the limit called RLIMIT_POSIXLOCKS.
RLIMIT_LOCKS is not much telling as well, RLIMIT_FLOCK would be better
IMHO.

I agree that we better follow Linux there.

> 
> 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.

I definitely do not want to go over the {pd,}ksh, zsh, bash, rc and
whatever else. Somebody who cares should contact the projects and
propose the changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20131031/8db74b1c/attachment.sig>