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

286 lines
8.3 KiB
C
Raw Normal View History

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
/* $NetBSD: svr4_resource.c,v 1.3 1998/12/13 18:00:52 christos 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>
#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;
return dosetrlimit(p, 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;
return dosetrlimit(p, 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
}