Re: recursive spinlocks. Shoot.

[Peter T. Breuer]

"Nick Piggin wrote:"
> Locking is an implementation issue, and as such I think you'll have
> to come up with a real problem or some real code. You must have some
> target problem in mind?

I'll butt back in here.

I found a problem when I made two drivers talk to each other.
Concretely a modified raid MD driver and a block device driver.

Each driver had ioctls that walked or modified a linear list, and locked
the list against other threads while running their subroutine in the
ioctl. To be concrete again, the lists were respectively the set of
raid arrays in which the block device found itself currently, and
the md drivers internal lists of arrays, component devices, etc.

The ioctls worked fine when used from user space.

Then I had the bright idea of getting the block driver to call the md
driver's ioctl automatically when a certain condition arose.  Concretely
again, I had the block device driver tell the md driver "setfaulty" when
the block device noticed an internal problem, and "hotadd" when it felt
cured.

Unfortunately, I had already gotten the md driver to tell the block
driver when it was booted out from or newly included in an array
(so that it could know if it should tell md when it felt ill or well).

The result was a call from the block driver to the md driver with a
lock held, and a rather unexpected call back from the md driver that
impotently tried to take the same lock.

Same thread.

Peter