On Tue, 11 Jun 2002 18:33:32 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
Well, it shouldn't be but it is. :-P However, one should try to avoid holding
locks except when necessary to maximize concurrency. Thus it is better to do
things like malloc() and free() while not holding locks
On Sun, 16 Jun 2002 04:10:23 -0700
Mike Makonnen [EMAIL PROTECTED] wrote:
I don't know if you recieved my earlier email about a bug that I found in
execve() while working on fixing the malloc w/ process lock held bugs.
Here's a simpler patch.
It fixes possible resource leaks and failure
On 10-Jun-2002 Mike Makonnen wrote:
Well, the real solution probably involves changing where we dink with
uidinfo structs so we bump the reference count on teh new one before
we grab the proc lock, change over to the new one while holding the
proc lock, then release the reference to the old
On Tue, 11 Jun 2002 04:36:41 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
This solution has the advantage that the only code that has to change is
the ucred and setuid/gid helper functions that already know about the
struct uidinfo functions. In fact only three functions not related
On Tue, 11 Jun 2002 13:07:03 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
Yes... if you don't go through the setuid/gid family of functions. Currently,
the only place uifind() is called, besides change_[re]uid() is in proc0_init. My
assumption was that you need to change the uidinfo
On Sat, 08 Jun 2002 10:57:32 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
Is the solution to this to use M_NOWAIT and continue re-trying
untill it succeeds? Is there on-going smp work in locking down struct
proc that will eliminate this problem?
Well, the real solution probably
On 08-Jun-2002 Mike Makonnen wrote:
On Sat, 08 Jun 2002 04:03:40 -0700 (PDT)
Hiten Pandya [EMAIL PROTECTED] wrote:
--- Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] wrote:
../vm/uma_core.c:1160
../../../vm/uma_core.c:1327: could sleep with process lock locked
from
