Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/compat/svr4/svr4_resource.c

288 lines
8.4 KiB
C
Raw Normal View History

Remplace kern.shortcorename sysctl with a more flexible sheme, core filename format, which allow to change the name of the core dump, and to relocate it in a directory. Credits to Bill Sommerfeld for giving me the idea :) The default core filename format can be changed by options DEFCORENAME and/or kern.defcorename Create a new sysctl tree, proc, which holds per-process values (for now the corename format, and resources limits). Process is designed by its pid at the second level name. These values are inherited on fork, and the corename fomat is reset to defcorename on suid/sgid exec. Create a p_sugid() function, to take appropriate actions on suid/sgid exec (for now set the P_SUGID flag and reset the per-proc corename). Adjust dosetrlimit() to allow changing limits of one proc by another, with credential controls.
1999-09-28 18:47:00 +04:00
/* $NetBSD: svr4_resource.c,v 1.5 1999/09/28 14:47:02 bouyer Exp $ */
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
/*-
* Copyright (c) 1998 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Christos Zoulas.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the NetBSD
* Foundation, Inc. and its contributors.
* 4. Neither the name of The NetBSD Foundation nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/proc.h>
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
#include <sys/file.h>
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
#include <sys/resource.h>
#include <sys/resourcevar.h>
#include <compat/svr4/svr4_types.h>
#include <compat/svr4/svr4_resource.h>
#include <compat/svr4/svr4_signal.h>
oops, forgot to include new files.
1999-09-07 22:20:18 +04:00
#include <compat/svr4/svr4_lwp.h>
#include <compat/svr4/svr4_ucontext.h>
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
#include <compat/svr4/svr4_syscallargs.h>
#include <compat/svr4/svr4_util.h>
static __inline int svr4_to_native_rl __P((int));
static __inline int
svr4_to_native_rl(rl)
int rl;
{
switch (rl) {
case SVR4_RLIMIT_CPU:
return RLIMIT_CPU;
case SVR4_RLIMIT_FSIZE:
return RLIMIT_FSIZE;
case SVR4_RLIMIT_DATA:
return RLIMIT_DATA;
case SVR4_RLIMIT_STACK:
return RLIMIT_STACK;
case SVR4_RLIMIT_CORE:
return RLIMIT_CORE;
case SVR4_RLIMIT_NOFILE:
return RLIMIT_NOFILE;
case SVR4_RLIMIT_VMEM:
return RLIMIT_RSS;
default:
return -1;
}
}
Clarify some signed/unsigned confusion with resource limit setting. Still don't understand you some old binaries try to use 5 for vmem instead of 6.
1998-11-30 18:46:33 +03:00
/*
* Check if the resource limit fits within the BSD range and it is not
* one of the magic SVR4 limit values
*/
#define OKLIMIT(l) (((int32_t)(l)) >= 0 && ((int32_t)(l)) < 0x7fffffff && \
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
((svr4_rlim_t)(l)) != SVR4_RLIM_INFINITY && \
((svr4_rlim_t)(l)) != SVR4_RLIM_SAVED_CUR && \
((svr4_rlim_t)(l)) != SVR4_RLIM_SAVED_MAX)
Clarify some signed/unsigned confusion with resource limit setting. Still don't understand you some old binaries try to use 5 for vmem instead of 6.
1998-11-30 18:46:33 +03:00
#define OKLIMIT64(l) (((rlim_t)(l)) >= 0 && ((rlim_t)(l)) < RLIM_INFINITY && \
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
((svr4_rlim64_t)(l)) != SVR4_RLIM64_INFINITY && \
((svr4_rlim64_t)(l)) != SVR4_RLIM64_SAVED_CUR && \
((svr4_rlim64_t)(l)) != SVR4_RLIM64_SAVED_MAX)
int
svr4_sys_getrlimit(p, v, retval)
register struct proc *p;
void *v;
register_t *retval;
{
struct svr4_sys_getrlimit_args *uap = v;
int rl = svr4_to_native_rl(SCARG(uap, which));
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
struct rlimit blim;
struct svr4_rlimit slim;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
if (rl == -1)
return EINVAL;
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
blim = p->p_rlimit[rl];
/*
* Our infinity, is their maxfiles.
*/
if (rl == RLIMIT_NOFILE && blim.rlim_max == RLIM_INFINITY)
blim.rlim_max = maxfiles;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
/*
* If the limit can be be represented, it is returned.
* Otherwise, if rlim_cur == rlim_max, return RLIM_SAVED_MAX
* else return RLIM_SAVED_CUR
*/
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
if (blim.rlim_max == RLIM_INFINITY)
slim.rlim_max = SVR4_RLIM_INFINITY;
else if (OKLIMIT(blim.rlim_max))
slim.rlim_max = (svr4_rlim_t) blim.rlim_max;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
else
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
slim.rlim_max = SVR4_RLIM_SAVED_MAX;
if (blim.rlim_cur == RLIM_INFINITY)
slim.rlim_cur = SVR4_RLIM_INFINITY;
else if (OKLIMIT(blim.rlim_cur))
slim.rlim_cur = (svr4_rlim_t) blim.rlim_cur;
else if (blim.rlim_max == blim.rlim_cur)
slim.rlim_cur = SVR4_RLIM_SAVED_MAX;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
else
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
slim.rlim_cur = SVR4_RLIM_SAVED_CUR;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
return copyout(&slim, SCARG(uap, rlp), sizeof(*SCARG(uap, rlp)));
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
}
int
svr4_sys_setrlimit(p, v, retval)
register struct proc *p;
void *v;
register_t *retval;
{
struct svr4_sys_setrlimit_args *uap = v;
int rl = svr4_to_native_rl(SCARG(uap, which));
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
struct rlimit blim, *limp;
struct svr4_rlimit slim;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
int error;
if (rl == -1)
return EINVAL;
limp = &p->p_rlimit[rl];
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
if ((error = copyin(SCARG(uap, rlp), &slim, sizeof(slim))) != 0)
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
return error;
/*
* if the limit is SVR4_RLIM_INFINITY, then we set it to our
* unlimited.
* We should also: If it is SVR4_RLIM_SAVED_MAX, we should set the
* new limit to the corresponding saved hard limit, and if
* it is equal to SVR4_RLIM_SAVED_CUR, we should set it to the
* corresponding saved soft limit.
*
*/
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
if (slim.rlim_max == SVR4_RLIM_INFINITY)
blim.rlim_max = RLIM_INFINITY;
else if (OKLIMIT(slim.rlim_max))
blim.rlim_max = (rlim_t) slim.rlim_max;
else if (slim.rlim_max == SVR4_RLIM_SAVED_MAX)
blim.rlim_max = limp->rlim_max;
else if (slim.rlim_max == SVR4_RLIM_SAVED_CUR)
blim.rlim_max = limp->rlim_cur;
if (slim.rlim_cur == SVR4_RLIM_INFINITY)
blim.rlim_cur = RLIM_INFINITY;
else if (OKLIMIT(slim.rlim_cur))
blim.rlim_cur = (rlim_t) slim.rlim_cur;
else if (slim.rlim_cur == SVR4_RLIM_SAVED_MAX)
blim.rlim_cur = limp->rlim_max;
else if (slim.rlim_cur == SVR4_RLIM_SAVED_CUR)
blim.rlim_cur = limp->rlim_cur;
Remplace kern.shortcorename sysctl with a more flexible sheme, core filename format, which allow to change the name of the core dump, and to relocate it in a directory. Credits to Bill Sommerfeld for giving me the idea :) The default core filename format can be changed by options DEFCORENAME and/or kern.defcorename Create a new sysctl tree, proc, which holds per-process values (for now the corename format, and resources limits). Process is designed by its pid at the second level name. These values are inherited on fork, and the corename fomat is reset to defcorename on suid/sgid exec. Create a p_sugid() function, to take appropriate actions on suid/sgid exec (for now set the P_SUGID flag and reset the per-proc corename). Adjust dosetrlimit() to allow changing limits of one proc by another, with credential controls.
1999-09-28 18:47:00 +04:00
return dosetrlimit(p, p->p_cred, rl, &blim);
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
}
int
svr4_sys_getrlimit64(p, v, retval)
register struct proc *p;
void *v;
register_t *retval;
{
struct svr4_sys_getrlimit64_args *uap = v;
int rl = svr4_to_native_rl(SCARG(uap, which));
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
struct rlimit blim;
struct svr4_rlimit64 slim;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
if (rl == -1)
return EINVAL;
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
blim = p->p_rlimit[rl];
/*
* Our infinity, is their maxfiles.
*/
if (rl == RLIMIT_NOFILE && blim.rlim_max == RLIM_INFINITY)
blim.rlim_max = maxfiles;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
/*
* If the limit can be be represented, it is returned.
* Otherwise, if rlim_cur == rlim_max, return SVR4_RLIM_SAVED_MAX
* else return SVR4_RLIM_SAVED_CUR
*/
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
if (blim.rlim_max == RLIM_INFINITY)
slim.rlim_max = SVR4_RLIM64_INFINITY;
else if (OKLIMIT64(blim.rlim_max))
slim.rlim_max = (svr4_rlim64_t) blim.rlim_max;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
else
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
slim.rlim_max = SVR4_RLIM64_SAVED_MAX;
if (blim.rlim_cur == RLIM_INFINITY)
slim.rlim_cur = SVR4_RLIM64_INFINITY;
else if (OKLIMIT64(blim.rlim_cur))
slim.rlim_cur = (svr4_rlim64_t) blim.rlim_cur;
else if (blim.rlim_max == blim.rlim_cur)
slim.rlim_cur = SVR4_RLIM64_SAVED_MAX;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
else
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
slim.rlim_cur = SVR4_RLIM64_SAVED_CUR;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
return copyout(&slim, SCARG(uap, rlp), sizeof(*SCARG(uap, rlp)));
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
}
int
svr4_sys_setrlimit64(p, v, retval)
register struct proc *p;
void *v;
register_t *retval;
{
struct svr4_sys_setrlimit64_args *uap = v;
int rl = svr4_to_native_rl(SCARG(uap, which));
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
struct rlimit blim, *limp;
struct svr4_rlimit64 slim;
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
int error;
if (rl == -1)
return EINVAL;
limp = &p->p_rlimit[rl];
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
if ((error = copyin(SCARG(uap, rlp), &slim, sizeof(slim))) != 0)
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
return error;
/*
* if the limit is SVR4_RLIM64_INFINITY, then we set it to our
* unlimited.
* We should also: If it is SVR4_RLIM64_SAVED_MAX, we should set the
* new limit to the corresponding saved hard limit, and if
* it is equal to SVR4_RLIM64_SAVED_CUR, we should set it to the
* corresponding saved soft limit.
*
*/
Make gerlimit(RLIM_NOFILE, rlp), return rlp->rlim_max == maxfiles, not RLIM_INFINITY like we do. Java uses rlim_max to allocate a data structure per file descriptor. what we do is bogus anyway, because: setrlimit(RLIM_NOFILE, {RLIM_INFINITY, RLIM_INFINITY}} sets the limit to { maxfiles, maxfiles } I undestand that this is so that if we change maxfiles via sysctl, processes can still use the new maximum, but it is probably more appropriate to return the current value of maxfiles (and maxproc) at every getrlimit call, even if the current value for either is RLIM_INFINITY. Anyway, java now works on the the sparc, on the i386 loses on setcontext().
1998-12-13 21:00:52 +03:00
if (slim.rlim_max == SVR4_RLIM64_INFINITY)
blim.rlim_max = RLIM_INFINITY;
else if (OKLIMIT64(slim.rlim_max))
blim.rlim_max = (rlim_t) slim.rlim_max;
else if (slim.rlim_max == SVR4_RLIM64_SAVED_MAX)
blim.rlim_max = limp->rlim_max;
else if (slim.rlim_max == SVR4_RLIM64_SAVED_CUR)
blim.rlim_max = limp->rlim_cur;
if (slim.rlim_cur == SVR4_RLIM64_INFINITY)
blim.rlim_cur = RLIM_INFINITY;
else if (OKLIMIT64(slim.rlim_cur))
blim.rlim_cur = (rlim_t) slim.rlim_cur;
else if (slim.rlim_cur == SVR4_RLIM64_SAVED_MAX)
blim.rlim_cur = limp->rlim_max;
else if (slim.rlim_cur == SVR4_RLIM64_SAVED_CUR)
blim.rlim_cur = limp->rlim_cur;
Remplace kern.shortcorename sysctl with a more flexible sheme, core filename format, which allow to change the name of the core dump, and to relocate it in a directory. Credits to Bill Sommerfeld for giving me the idea :) The default core filename format can be changed by options DEFCORENAME and/or kern.defcorename Create a new sysctl tree, proc, which holds per-process values (for now the corename format, and resources limits). Process is designed by its pid at the second level name. These values are inherited on fork, and the corename fomat is reset to defcorename on suid/sgid exec. Create a p_sugid() function, to take appropriate actions on suid/sgid exec (for now set the P_SUGID flag and reset the per-proc corename). Adjust dosetrlimit() to allow changing limits of one proc by another, with credential controls.
1999-09-28 18:47:00 +04:00
return dosetrlimit(p, p->p_cred, rl, &blim);
Deal with {get,set}rlimit{,64} properly, respecting the RLIM_INFINITY, RLIM_SAVED_MAX, and RLIM_SAVED_CUR values. We should fix our own implementation to do this and use unsigned numbers for rlim_t as solaris does.
1998-11-29 00:53:02 +03:00
}