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> > ../../../kern/kern_prot.c:511
>> > ../../../vm/uma_core.c:1327: could sleep with "process lock" locked
> from>
>> > Hope this help. Do you think these errors are alarming ?
>> > I mean, do you recommend me to recopile my kernel again ?
>> > (please noooooo, it takes me a lot of time to recompile whatever
> thing :)>
>
> I also get these and I figured they're as good an excuse as any to jump
> into the kernel code :-} This particular one (and others related to the
> setuid/gid family of functions) occur because some time after PROC_LOCK
> is called in set{uid,euid} and further down the call stack uidfind()
> allocates some memory specifying the M_WAITOK flag.
>
> 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 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 one after we are done.
> Cheers,
> Mike Makonnen
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
