I have a linux kernel driver and a user app that interacts with it. The kernel driver has a deadlock in it. I came accross this feature in the linux kernel called \"lockdep\
To enable lockdep feature, edit .config file through menuconfig:
make menuconfig
And enable following in Hacking Options:
1. [*] Detect Hard and Soft Lockups
2. [*] Detect Hung Tasks
3. [*] RT Mutex debugging, deadlock detection
4. -*- Spinlock and rw-lock debugging: basic checks
5. -*- Mutex debugging: basic checks
6. -*- Lock debugging: detect incorrect freeing of live locks
7. [*] Lock debugging: prove locking correctness
8. [*] Lock usage statistics
Recompile the kernel:
make ARCH=i386 -j4 //whatever your arch is
Now, boot the new kernel image, under /proc you should see the following new folders:
/proc/lockdep
/proc/lockdep_chains
/proc/lockdep_stat
/proc/locks
/proc/lock_stats
Now, insert the module you think that is causing the error, and access it with your user application (or whatever way you use to run your driver module). If the app deadlocks(hangs), do a:
ps -aux | grep <app_name>
you should see a +D (uninterruptible sleep) state for your app, do a:
dmesg
The log it prints will include the function/file causing the deadlock.
That's it!
There is not much to it – the lockdep code will simply print a description of the situation and a stack backtrace to the kernel log when it encounters a locking sequence that potentially deadlocks. You just have to watch your kernel output (via dmesg
or serial line or whatever you use).
The lockdep code debugs only locks, it can not warn you about deadlocks that arise from something else.