> YAMAMOTO Takashi wrote:
> >> YAMAMOTO Takashi wrote:
> >>>> we use that argument to pass the
> >>>> process requesting the rlimit change
> >>> can it be different from curproc?
> >> no. that's what the first version of the fix, as you can see.
> >>
> >> however, keep in mind that the context may be forwarded to a userland
> >> daemon or a different machine on the network for decision, so I don't
> >> think we can rely on curproc/curlwp here...
> > 
> > who decided to forward it can save the curproc by itself.
> 
> that's what I also thought initially, but I believe this will be
> somewhat ugly: part of the context that is requested for decision
> making will need to be "generated" by the secmodel code itself, rather
> than just forwarded.

"p = curproc" doesn't generate it.

> are you absolutely insisting on not passing the requesting proc? :)

no, as far as its usage is well-defined. 
(we have many functions which have proc/lwp pointer arguments with
too vague semantics.)

YAMAMOTO Takashi