Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: recursive spinlocks. Shoot. | Date | Thu, 22 May 2003 06:42:15 +0200 (MET DST) |
| |
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |