I'm trying to debug a deadlock problem I'm seeing in a kernel module, and
I wonder if someone could answer some questions I had about spinlocks.
We've got a model where we have interrupt threads hand off work entries
to kthreads (so that the interrupt threads aren't blocked for too long).
The interrupt thread enqueues a work entry for the kthread, then wakes
up the kthread. Then, the kthread processes the work entry. The work
queue is protected by a spin lock.
Unfortunately, the kthread waits for work entries by calling msleep().
msleep() expects a regular sleep lock to be handed in, not a spin lock.
I would *expect* that this would result in the kthread blocking
interrupts when it calls mtx_lock_spin(), and since msleep() won't
re-enable interrupts (as far as I know), I would expect total starvation
of the kthread. But that's not what I'm seeing...I'm actually seeing the
interrupt thread getting called, but it's blocking on the
mtx_lock_spin().
The interrupt callback code looks like:
mtx_lock_spin(&spin_lock); <--- blocking here ***
/* Add a new work entry */
mtx_unlock_spin(&spin_lock);
wakeup(channel);
The kthread code looks like:
for (;;) {
mtx_lock_spin(&spin_lock);
while ( /* Work queue is empty */ ) {
msleep(channel, &spin_lock, PI_DISK, str, 0);
}
/* Remove a work entry */
mtx_unlock_spin(&spin_lock);
/* Process the work entry we just removed */
}
My questions to you:
- What are the ill effects of handing a spin lock to msleep?
- I noticed that no one seems to use msleep with spin locks, nor have a
need to do so. This leads me to believe that this producer/consumer
programming model show above is incorrect. Should we be doing this
differently?
Many thanks,
Rob A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
