Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Jul 2002 22:50:20 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Mike Makonnen <makonnen@pacbell.net>
Cc:        bright@mu.org, freebsd-smp@FreeBSD.ORG
Subject:   Re: Getting resource limits out from under Giant
Message-ID:  <XFMail.20020713225020.jhb@FreeBSD.org>
In-Reply-To: <20020713152319.75c416a2.makonnen@pacbell.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On 13-Jul-2002 Mike Makonnen wrote:
> 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.

Why not just do a simple change: don't drop the locks so quick, but go
ahead and do the modify limit step after using your preallocated memory
to do the copy-on-write.  Then you can drop your locks and free any
memory using cached pointers.  No need for a loop and much simpler.
Basically, all you need to do is move your 'free some memory' step
down to the bottom, then you can immediately go from the copy-on-write
step to the modify limits step.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.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?XFMail.20020713225020.jhb>