YAMAMOTO Takashi wrote:
>> 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.)

I understand your meaning about "the requesting process" being always
curproc (technically, the currently executing process is doing the
request, yes :) but I still think that we should aim for full context
in the kpi and not "the 4 arguments + curproc for this action".

other than that, is it okay to commit?

-e.