lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Rationale for RLIMIT_MEMLOCK?
Joerg Schilling wrote:

> RLIMIT_MEMLOCK did first apear in BSD-4.4 around 1994.
> The iplementation is incomplete since then and partially disabled (size check
> for mmap() in the kernel) on FreeBSD as it has been 1994 on BSD-4.4
>
> FreeBSD currently uses a default value of RLIMIT_INFINITY for users.

And while it does that (or in fact, rather not distinguish between root and
unprivileged users), mlock() and mlockall() are privileged operations on
FreeBSD.

> I could add this piece of code to the euid == 0 part of cdrecord:
>
> LOCAL void
> raise_memlock()
> {
> #ifdef RLIMIT_MEMLOCK
> struct rlimit rlim;
>
> rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY;
>
> if (setrlimit(RLIMIT_MEMLOCK, &rlim) < 0)
> errmsg("Warning: Cannot raise RLIMIT_MEMLOCK limits.");
> #endif /* RLIMIT_NOFILE */
> }

Except that your new #endif comment is wrong, that is exactly what I
suggested and what I've tried and found working.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-25 17:04    [W:0.309 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site