Re: scheduling with io_lock held in 2.4.6

[Andrew Morton]

"Peter T. Breuer" wrote:
> 
> "A month of sundays ago Andrew Morton wrote:"
> > "Peter T. Breuer" wrote:
> > >
> > > "Andrew Morton wrote:"
> > > > "Peter T. Breuer" wrote:
> > > > >   Aug 17 01:41:01 xilofon kernel: Scheduling with io lock held in process 1141
> > >
> > > > Replace the printk with a BUG(), feed the result into ksymooops.
> > > > Or use show_trace(0).
> 
> > Suggest you add the BUG() when it occurs, feed it into ksymoops
> > and post it.  All will be revealed.
> 
> Whilst I've viewed dozens of the oopses, the call trace hasn't
> enlightened me (there's usually an interrupt in it, which throws me),

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
sleeps, either.

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.

-