>> I believe there is a race condition here. [...]
> Hum, this can occur with a limit change as well, as limcopy() may
> sleep on the plimit_pool pool too, and limcopy() will copy changed
> rlimits when it wakes up.

Hmm, you're right.

> Is is less bad than copying overruning a malloc'd area, but still ...

Agreed (on both counts).

> We should decerase the ref_count *after* limcopy() as returned,

Right, I think.

> So I propose to move all (p->p_limit->p_refcnt--) to after the limcopy()
> call, and change it to:
>         if (--p->p_limit->p_refcnt == 0)
>             pool_put(&plimit_pool, p->p_limit);

Um, you need to not just pool_put, but also free
p->p_limit->pl_corename if it's not defcorename.  Since this makes two
places that do basically the same thing (free a p_limit if its refcount
is zero) perhaps a routine to do this should be created?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B