Re: kernel analyser to detect sleep under spinlock

From: Peter T. Breuer
Date: Sat Nov 13 2004 - 07:32:32 EST

Peter T. Breuer <ptb@xxxxxxxxxxxxxx> wrote:
> I'll undertake a survey of the current kernel.

Just for kicks, I started with the DAC960.c driver (alphabet ..), and
it registered 6 alarms!

Linux Driver for Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers

Copyright 1998-2001 by Leonard N. Zubkoff <lnz@xxxxxxxxxxxxx>

* function line calls (locks)
* - /usr/local/src/linux-2.6.3/drivers/block/DAC960.c
!! DAC960_BA_InterruptHandler 5219 DAC960_V2_ProcessCompletedCommand (1)
!! DAC960_LP_InterruptHandler 5262 DAC960_V2_ProcessCompletedCommand (1)
!! DAC960_V1_ExecuteUserCommand 5869 DAC960_WaitForCommand (1)
!! DAC960_V2_ExecuteUserCommand 6132 DAC960_WaitForCommand (1)
!! DAC960_gam_ioctl 6663 DAC960_WaitForCommand (1)
!! DAC960_gam_ioctl 6688 DAC960_WaitForCommand (1)

The ProcessCompletedCommand thing really is called under spinlock, but
it appears to be detected as sleepy because it calls kmalloc (and
kfree), however it calls kmalloc with GFP_ATOMIC, so it's not sleepy
and that's a false alarm. Ho hum ... I'll have to detect that.

The WaitForCommand is also definitely called under spinlock ... and is
thought to be sleepy because it calls schedule! Well, it calls
__wait_event(Controller->CommandWaitQueue, Controller->FreeCommands);
Is that going to schedule? I suppose logically it should.

Anyway, that looks a legitimate complaint:

spin_lock_irqsave(&Controller->queue_lock, flags);
while ((Command = DAC960_AllocateCommand(Controller)) == NULL)
spin_unlock_irqrestore(&Controller->queue_lock, flags);

Looks like it waits under spinlock to me!

I'll go write the generic inference engine required to make this a bit
more accurate still.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at