cvs commit: src/sys/kern subr_param.c

Alfred Perlstein alfred at freebsd.org
Mon Nov 19 13:07:53 PST 2007


* Roman Divacky <rdivacky at freebsd.org> [071119 11:42] wrote:
> On Mon, Nov 19, 2007 at 07:41:11PM +0100, Ulrich Spoerlein wrote:
> > On Sun, 18.11.2007 at 18:53:28 -0800, Alfred Perlstein wrote:
> > > * Roman Divacky <rdivacky at FreeBSD.org> [071118 14:42] wrote:
> > > > On Tue, Oct 16, 2007 at 10:40:54AM +0000, Alfred Perlstein wrote:
> > > > >   Modified files:
> > > > >     sys/kern             subr_param.c 
> > > > >   Log:
> > > > >   Export maxswzone, maxbcache, maxtsiz, dfldsiz, maxdsiz, dflssiz, maxssiz,
> > > > >   and sgrowsiz via sysctl.
> > > > 
> > > > why is maxssiz RD_ONLY? its used only in exec_new_vmspace() for setting the default
> > > > stack area size and only if thats not set by sysentvec, so it's RW already just
> > > > not defined so.
> > > > 
> > > > also... dflssiz is not used at all, and the "default stack size" is set by maxssiz
> > > 
> > > If you think it can be safely changed, then go for it!
> > 
> > Could this be done for maxdsiz, too? It's kinda sad you need to reboot a
> > FreeBSD system to work around the 512MB data size limit (in this day and
> > age, processes can easily hit the 512MB barrier)
> 
> as I can see the maxdsiz is used only as a barrier for rlimit.. I see no harm
> in changing that to RW too..
> 
> I already asked kib@ if he's willing to commit this, waiting for answer...

Please use a SYSCTL_PROC so some basic sanity checks could be made to keep
the system functioning, basically prevent too low or insanely high
values from being set.

-- 
- Alfred Perlstein


More information about the cvs-src mailing list