On 11-Sep-2002 Don Lewis wrote:
> On 11 Sep, John Baldwin wrote:
>>
>> On 11-Sep-2002 Don Lewis wrote:
>>> On 10 Sep, Don Lewis wrote:
On 10 Sep, Nate Lawson wrote:
> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
> before grabbing the proc lock. Dropp
On 11 Sep, John Baldwin wrote:
>
> On 11-Sep-2002 Don Lewis wrote:
>> On 10 Sep, Don Lewis wrote:
>>> On 10 Sep, Nate Lawson wrote:
>>>
I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
before grabbing the proc lock. Dropping locks in the middle or
pre-alloca
On 11-Sep-2002 Don Lewis wrote:
> On 10 Sep, Don Lewis wrote:
>> On 10 Sep, Nate Lawson wrote:
>>
>>> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
>>> before grabbing the proc lock. Dropping locks in the middle or
>>> pre-allocating should always be a last resort.
>>
On 10 Sep, Don Lewis wrote:
> On 10 Sep, Nate Lawson wrote:
>
>> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
>> before grabbing the proc lock. Dropping locks in the middle or
>> pre-allocating should always be a last resort.
>
> That is ok as long as there aren't othe
On 10 Sep, Nate Lawson wrote:
> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
> before grabbing the proc lock. Dropping locks in the middle or
> pre-allocating should always be a last resort.
That is ok as long as there aren't other threads that can mess things up
after
On Tue, 10 Sep 2002, Don Lewis wrote:
> On 7 Sep, Garrett Wollman wrote:
> > I just noted the following:
> >
> > ../../../vm/uma_core.c:1332: could sleep with "process lock" locked from
>../../../kern/kern_exec.c:368
> > lock order reversal
> > 1st 0xc438e6a8 process lock (process lock) @ ../.
On 7 Sep, Garrett Wollman wrote:
> I just noted the following:
>
> ../../../vm/uma_core.c:1332: could sleep with "process lock" locked from
>../../../kern/kern_exec.c:368
> lock order reversal
> 1st 0xc438e6a8 process lock (process lock) @ ../../../kern/kern_exec.c:368
> 2nd 0xc0413d20 fileli
