> Thanks for the help here! I am afraid I looked at these cli() calls
> for a couple of days. I knew there was a problem but I didn't know what
> to do about it. Does the Linux Device drivers book discuss the spin_lock
> stuff, and when to use that instead of cli()? If it does, I missed it
> entirely.
I dunno, I've never read any of the Linux internals books :-).
> For the ignorant amoung us (i.e. me), could you explain why this
> patch is the Right Thing(tm). Enquiring minds want to know.
It isn't the cli that's the problem - it's the sti (allow interrupts).
In the past (i.e. 2.0) we used one big lock around the kernel
so as far as kernel internals were concerned we only had one
processor so cli...sti would guarantee mutual exclusion. The block
request handler in ll_rw_blk.c did a cli before calling the
device specific request handler. In the case of sbpcd/cdu31 (and
indirectly cm206) they grabbed the request off the list and did
a sti to allow other interrupts to be serviced while they worked.
Now, along comes fine(er) grained SMP in 2.1. More than one
processor can be in the kernel at the same time. The block
request handler still disables interrupts but also grabs a spin
lock to prevent other processors changing the request lists at
the same time. Unfortunately the CD drivers didn't know that
so when they enabled interrupts they still had the spin lock
held. If an interrupt occurs while they are working and tries
to do something with a block request list it will spin waiting
for the spin lock to become free. If the interrupt has just
been handled by the same processor that was doing the CD driver
request it will block forever because the spin lock is never
going to be released. Once that happens every processor will
eventually block when it needs to do some block I/O...
Mike
-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 | | RG40 1XG, ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/