Date: Sat, 02 Jun 2012 14:30:19 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Julian Elischer <julian@FreeBSD.org> Cc: Adrian Chadd <adrian@FreeBSD.org>, Doug Barton <dougb@FreeBSD.org>, d@delphij.net, Eitan Adler <lists@eitanadler.com>, freebsd-arch@FreeBSD.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Edward Tomasz Napierala <trasz@FreeBSD.org>, Bryan Drewery <bryan@shatow.net> Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? Message-ID: <4FC9F94B.8060708@FreeBSD.org> In-Reply-To: <4FC95A10.7000806@freebsd.org> References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> <CAJ-VmokY%2Bpgcq999NHShbq-3rK3=oeWT2WY7NmTvVdXOHZJhdg@mail.gmail.com> <CAF6rxgmDW21aPJ5Mp6Tbk1z02ivw4UPhSaNEX%2BWiu7O0v13skA@mail.gmail.com> <20120517055425.GA802@infradead.org> <4FC762DD.90101@FreeBSD.org> <4FC81D9C.2080801@FreeBSD.org> <4FC8E29F.2010806@shatow.net> <4FC95A10.7000806@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 02/06/2012 03:10 Julian Elischer said the following: > I'd go a different route. > I'd have it inherited, and I'd have the value be 0 by default, but settable to > some different value at login.conf, or by an ancestor with root privs. I think that this is how the limits work in general :-) I agree that defaulting the limit to 0 for non-privileged users is a good idea, at least at the beginning. For super-user we might want to keep the limit uncapped. Some further technical observations: o I was overly optimistic about _full_ support for RLIMIT_MEMLOCK - mlockall() doesn't support itat the moment and I am not sure if it is easy to implement the support for the MCL_FUTURE case. o Currently the default class in default login.conf has memorylocked=unlimited - not very smart. o There is also vm.max_wired sysctl (with no equivalent tunable), which specifies number of _pages_ that can be wired system wide (by both kernel and userland). But note that the limit applies only to userland requests, the kernel is allowed to wire new pages even when the limit is exceeded. By default the limit is set to 1/3 of available pages. So watch out for this limit when using ZFS, ZFS can easily starve userland. o I've just discovered :-) that we also have RCTL/RACCT framework (not enabled by default) aka "Resource Accounting" / "Resource Limits", which seems to parallel the conventional limits in many categories including the locked memory. Not sure why we have that and if the interactions between conventional limits, resource limits and privileges would be easy to untangle. o A general observation that our way of setting resource limits via login classes (login.conf) seems to be inferior to limits.conf way of Linux. More about the last point. In addition to the traditional users and groups we also have login classes. Initial (conventional) resource limits can be set only via login.conf, i.e. via the classes. The classes can be assigned only in master.passwd and thus only to users. So if I want to increase some limit for a group, then I have to create (and maintain) a parallel class and assign that class to all users in question. Now imagine a case of a user being in several groups. Ability to specify the limits on per-user/per-group basis like it is done with Linux limits.conf seems to be more convenient. The new rctl framework also allows to set resource limits for "process, user, login class, or jail". 'group' is missing from the list. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC9F94B.8060708>