Date: Thu, 31 Oct 2013 11:40:58 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Stefan Neudorf <BM-2cXppXU4T67w7j6NCir9T1WdzBHmFgBnLj@bitmessage.ch> Subject: Re: svn commit: r256850 - in head: bin/sh etc lib/libc/sys lib/libutil usr.bin/limits usr.bin/procstat Message-ID: <20131031094058.GH59496@kib.kiev.ua> In-Reply-To: <20131030212052.GA3516@stack.nl> References: <201310211646.r9LGkDl5012906@svn.freebsd.org> <20131030.86fvriud2y@bitmessage.ch> <20131030212052.GA3516@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--1vEdgMWljt97yA53 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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@FreeBSD.org> writes: >=20 > > > Author: kib > > > Date: Mon Oct 21 16:46:12 2013 > > > New Revision: 256850 > > > URL: http://svnweb.freebsd.org/changeset/base/256850 >=20 > > > Log: > > > Add a resource limit for the total number of kqueues available to t= he > > > user. Kqueue now saves the ucred of the allocating thread, to > > > correctly decrement the counter on close. >=20 > > > Under some specific and not real-world use scenario for kqueue, it = is > > > possible for the kqueues to consume memory proportional to the squa= re > > > of the number of the filedescriptors available to the process. Lim= it > > > allows administrator to prevent the abuse. >=20 > > > This is kernel-mode side of the change, with the user-mode enabling > > > commit following. >=20 > > > Reported and tested by: pho > > > Discussed with: jmg > > > Sponsored by: The FreeBSD Foundation > > > MFC after: 2 weeks >=20 > > > 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 >=20 > > kqueues limit isn't documented in sh(1) and limits(1) manpages. >=20 > I can do this in the next few days. Thank you, appreciated. >=20 > > > Modified: head/bin/sh/miscbltin.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > --- 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[] =3D { > > > #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' } > > > }; > > > =20 >=20 > > 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 (posixlock= s) > > from DragonFly. Do you anticipate FreeBSD never adds RLIMIT_POSIXLOCKS > > support or would use incompatible option switch? >=20 > > http://www.zsh.org/mla/workers/2013/msg00984.html > > http://gitweb.dragonflybsd.org/dragonfly.git?a=3Dsearch&h=3DHEAD&st=3Dc= ommit&s=3Dposixlocks >=20 > 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. >=20 > 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. >=20 > 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. >=20 > > > Modified: head/usr.bin/limits/limits.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > --- 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) >=20 > > This adds limits -e support only for sh, csh, tcsh. What about other > > shells that already support sbsize and swapuse extensions? >=20 > 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. --1vEdgMWljt97yA53 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSciWpAAoJEJDCuSvBvK1BFLUP/2+fBHUUfwTWAsa5KJ73NYlO fUgbUrCGUi5fNr5l85Jsye7sHxyXHV2MjDK8H2gu17msbig97QeT741B2VtISk3P Q7YkbVI4Pg0hVBbZGbSVnzqFDl8GIhJkuYD9ZdahDawtEteuobFEC5/VqkO9kKxR zPdVamZtD7FmOS2z6x5zYt6FxwRCOCGupXqeKhdCC+MgIgL/IggoqM7sLGyVdPwJ aI1UWZLYlMqWDGkbPKDT/O0jlqZfJ2U04ragOo+vFwy3GnXpAZFI0/qymAIBjkPk yukaVlmiQ6zO7h+kElrWBqV1Z5lgUnbrr9HrYQt5sXT5vDa39bT8W2aBQY76AWPt tedU8vUCwho9PJajDsgTKyK9mnbH/L271fsV/BLplCUK6ikAmBF5qG5hucfMQtwX FKPY+4+nHmX/rasKYzeD40tqlkbpaVPYS8R5ve1Od26TDQn4OoUaQrqMJM4KYcA7 LUfBvNl82i/P9zLfbF8kcEfX79MGqe+9TKyOJgkvU+KT4tP7Xh/00w/zO5f1i7yi QxH7axTVRh63LZulHbz+lSJHHrbcim3tMPh0dNBhDKkD7fBT8hhYcv7HVmxt0/tj 0sGIrtzusiiVR4IOmYPYahvn1z5Hn+JM8tJHUv6izBgX7JXF+uI6/2P3kUr9NoBv uG3aiX4OucZWBAGuf9FQ =gu9Y -----END PGP SIGNATURE----- --1vEdgMWljt97yA53--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131031094058.GH59496>