Yes, there are often interrupt entrails on the stack. If you can,
generate that trace and send it....
> and adding the oops seemed to destabilize the kernel. Does "atomic_set"
> really work? It seems to be just an indirected write. I am suspicious
> that the atomic writes I tried to do for the data aren't atomic. The
> expansion of atomic_set(&io_request_lock_pid, current_pid()) is:
> ((( &io_request_lock_pid )->counter) = ( current_pid() )) ;
That's OK - this is the x86 version of atomic_set and yes, we
assume that the compiler will generate a single write for the
store. All the x86 MP cache coherency stuff takes care of
the atomicity wrt other CPUs.
> I'll see ... btw, the problem seemed to track further to
> blkdev_release_request. Aha aha aha aha aha ... the comment at the
> top of that function says that not only must the io_request_lock be
> held but irqs must be disabled. Do they mean locally or globally? I'm
> holding them off locally (via spin_lock_irqsave).
Locally. You need to take spin_lock_irqsave(&io_request_lock)
before calling that function. It doesn't call anything which
It may simplify your oops tracing to remove all the `inline'
qualifiers in ll_rw_blk.c, BTW. They tend to obscure things.
They should in fact be taken out permanently - someone went
absolutely insane there.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/