Date: Wed, 28 Feb 2001 14:49:06 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Peter Dufault <dufault@hda.hda.com> Cc: hackers@FreeBSD.ORG Subject: Re: memorylocked resource (was "Setting memory allocators...") Message-ID: <200102282249.f1SMn6N93107@earth.backplane.com> References: <200102281332.f1SDWPD27689@hda.hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm. Well, mlock() is one of those system calls that virtually
nobody has worked on since inception. The most I've done with it
has been to fix bugs. The resource issues for mlock() aren't
really good enough to prevent misuse in a general multiuser system.
The resource is per-process rather then per-user, and in fact not
even implemented. And the locked memory is not advisory so there is
no way for the kernel to recover it under heavy load conditions until
the process releases it or exits.
If you grep for RLIMIT_MEMLOCK you find a minimal implementation of
the resource limit in vm/vm_mmap.c. 'pmap_wired_count' is not defined,
so the implementation is to be root-only and to ignore the resource limit.
Even with pmap_wired_count implemented the implementation is per-process,
which is not sufficient protection.
-Matt
:Why is the mlock(2) call restricted to the super user instead
:of enforcing it through per-user or per-login class limits?
:I was checking to see if most of the pieces were in place for
:"mlockall(MCL_FUTURE)" and noticed the "memorylocked infinity"
:setting in limits (I didn't know about memorylocked). Setting
:"memorylocked 0" for normal users is a flexible way to address
:this, then create a special class of programs that are permitted
:to do some locking.
:
:Along the same lines (matt probably knows the answer) is it
:easy to force paging in and locking down of any memory associated
:with a process so that mlockall(MCL_FUTURE) together with
:an appropriate memorylocked limit gives the requested
:memory semantics? I'd have to check through the specs to see
:how mmap() is supposed to play with mlockall().
:
:Please leave aside most resource management issues
:for now, I'm assuming the main use for this is debugged
:small closed embedded systems, only bring up kickers.
:
:Peter
:
:--
:Peter Dufault (dufault@hda.com) Realtime development, Machine control,
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102282249.f1SMn6N93107>