Re: panic since changes to kern_umtx.c

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