Date: Mon, 26 May 2003 17:08:21 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bryan Liesner <bleez@verizon.net> Cc: freebsd-current@freebsd.org Subject: Re: panic since changes to kern_umtx.c Message-ID: <3ED2AC75.3408574E@mindspring.com> References: <20030526120106.S488@gravy.homeunix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bryan Liesner wrote:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> 0xc0136be7 is in heap_up (../../../cam/cam_queue.c:345).
> 345 if (queue_array[i]->priority == queue_array[j]->priority)
Pretty much the only way this can happen is for i or j to be
out of range, or for queue_array[?] to be NULL (the first
element in a cam_pinfo is "priotity", so this corresponds to
the offset of 0 from the start of the struct for that member).
I would have to say that this is probably the result of a
bogus wakeup, or more general corruption of kernel memory as
a result of Jeff's move to a seperate queue mutex for calling
from user space.
Actually, the one suspicious thing is that it walks the thread
list in the proc without holding the proc lock; the block
comment above this code is not true any more now, e.g.:
/*
* Since we own the mutex and the proc lock we are free to inspect
* the blocked queue. It must have one valid entry since the
* CONTESTED bit was set.
*/
[ ... ]
FOREACH_THREAD_IN_PROC(td->td_proc, td0)
if (td0 == (struct thread *)blocked)
break;
The same unprotected (broken) loop occurs in both _umtx_lock()
and _umtx_unlock().
It's strange that it would show up in cam, but at least it's
repeatable. 8-).
-- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED2AC75.3408574E>