Date: Fri, 12 Jul 2002 01:16:32 -0700 From: Alfred Perlstein <bright@mu.org> To: Mike Makonnen <makonnen@pacbell.net> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Getting resource limits out from under Giant Message-ID: <20020712081632.GJ97638@elvis.mu.org> In-Reply-To: <20020712010734.40b40b77.makonnen@pacbell.net> References: <20020710042149.26b39b62.makonnen@pacbell.net> <20020712010734.40b40b77.makonnen@pacbell.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Mike Makonnen <makonnen@pacbell.net> [020712 01:07] wrote: > On Wed, 10 Jul 2002 04:21:49 -0700 > Mike Makonnen <makonnen@pacbell.net> wrote: > > > Hello folks, > > > > I took a stab at getting resource limits out from under Giant. > > The patch is at http://home.pacbell.net/makonnen/limits.giant.patch > > > > Comments? > > Ok, I've broken it down into 3 separate diffs. > http://home.pacbell.net/makonnen/limits.tar.gz > > 1. Touches sys/resourcevar.h > - add a mutex to struct plimit > - define 2 macros: LIM_LOCK and LIM_UNLOCK > Touches kern/kern_resource.c > - add 3 functions: limget(), limhold(), limfree() > - modify limcopy() to take two arguments, the new and the old plimits > structure. > > 2. Touches users of resource limits > - These are exit1(), fork1(), proc0_init(), and acct_process() > > 3. Actually removes lock/unlock of Giant, and GIANT_REQUIRED Cool! Are you sure that no one can come in and mess with some other process's p->p_limit structure? If so you may need to protect it via the proc lock. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020712081632.GJ97638>