Date: Sat, 13 Jul 2002 15:23:19 -0700 From: Mike Makonnen <makonnen@pacbell.net> To: John Baldwin <jhb@FreeBSD.ORG> Cc: freebsd-smp@FreeBSD.ORG, bright@mu.org Subject: Re: Getting resource limits out from under Giant Message-ID: <20020713152319.75c416a2.makonnen@pacbell.net> In-Reply-To: <XFMail.20020712140932.jhb@FreeBSD.org> References: <20020712020633.6a66f187.makonnen@pacbell.net> <XFMail.20020712140932.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Jul 2002 14:09:32 -0400 (EDT) John Baldwin <jhb@FreeBSD.ORG> wrote: > > > You need to ensure you have a stable reference to the limits > structure. If you are dereferencing p_limit you need to use the proc > lock to protect reading that pointer. The lock also ensure the value > is up to date. > I see what you mean: foolimit = p->p_limit->pl_rlimit[FOOLIMIT].rlim_cur; is OK. But plim = p->p_limit; ... ... foolimit = p->p_limit->pl_rlimit[FOOLIMIT].rlim_cur; needs to lock both the proc and the limit. Even better, it should use the first form if it can. The part I am not clear about is when modifying a value in the limits structure. There is one instance in the patch where I do this: a: allocate some memory lock proc lock p->plimit check if we must copy-on-write do so if necessary unlock plimit unlock proc free some memory lock p->plimit if conditions have changed and we must do a copy-on-write goto a modify limits as necessary My reasoning for dropping both locks in the middle and reaquiring only the limit lock is that anyone who might mess with our p->plimit must aquire both the proc and the limit lock. So, as long as I have the limit lock, there isn't any chance that it will go stale on me. I will work on the patch some more this weekend and repost. Cheers, Mike Makonnen 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?20020713152319.75c416a2.makonnen>