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. Dropping locks in the middle
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.
That is ok as
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-allocating should always be
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 filelist lock
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 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 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 other threads
