Tools for checking incorrect usage of locking techniques in k-space

[Kumar amit mehta]

On Sat, Oct 27, 2012 at 09:26:51PM +0530, Srivatsa Bhat wrote:
> On Sat, Oct 27, 2012 at 10:11 AM, Kumar amit mehta <gmate.amit at gmail.com> wrote:
> > Hi,
> >
> > I recently came across this tool called KEDR[1] for checking memory leak in
> > kernel modules. I'm using it to check If my trivial kernel modules (based on
> > LDD3 examples) are leaking memory. I was wondering if there exist a similar
> > tool for checking incorrect usage of locking techniques implemented by kernel
> > module.
> >
> 
> You can make use of the in-kernel "lockdep" framework to check your locking.
> Just enable it in your .config, and build and boot your kernel. Lockdep detects
> a variety of locking problems at run time and warns you if there is a
> possibility
> of deadlock etc.
> 
> Regards,
> Srivatsa S. Bhat
Thank you Srivatsa. It seems that lockdep framework is enabled on my running
kernel.

<snip>
amit at ubuntu:/boot$ egrep -i "debug_kernel|lockdep" config-3.2.0-29-generic-pae 
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_DEBUG_KERNEL=y
<snip>

If above configuration is all that I need, then should I be seeing warning/error
messages in kernel logs(/var/log/kern.log) when there is inconsistency in
locking ? To test my hypothesis, I modified my simple kernel module to
deliberately induce locking error (After initializing read-write semaphore, I call 
down_write() and do not free this semaphore lock by commenting out up_write() 
invocation). But still I don't see any error or warning message trace in kernel
logs, I think, I'm missing something. I've just now found out that there is a 
tutorial on runtime locking correctness validator[1] under Documentation. I'll 
go through it.

On the other hand, I found this KEDR utility very simple and accurate in finding
out the erroneous memory handling. For example, this is how the KEDR reports
memory leakage in my kernel module:
<snip>
2670043 Oct 27 06:32:38 ubuntu kernel: [16963.930621] Inside echo_exit: kfree()
2670044 Oct 27 06:32:38 ubuntu kernel: [16963.930886] [leak_check] LeakCheck has
detected possible memory leaks:
2670045 Oct 27 06:32:38 ubuntu kernel: [16963.930897] [leak_check] Address:
0xeeafbb70, size: 9; stack trace of the allocation:
2670046 Oct 27 06:32:38 ubuntu kernel: [16963.930907] [leak_check] [<f86ac0b2>]
echo_write+0x42/0xd0 [echo] 
2670047 Oct 27 06:32:38 ubuntu kernel: [16964.001413] [leak_check] [<c11448bf>]
vfs_write+0x8f/0x160
2670048 Oct 27 06:32:38 ubuntu kernel: [16964.001421] [leak_check] [<c1144b9d>]
sys_write+0x3d/0x70
2670049 Oct 27 06:32:38 ubuntu kernel: [16964.002214] [leak_check] [<c15ac7df>]
sysenter_do_call+0x12/0x28
2670050 Oct 27 06:32:38 ubuntu kernel: [16964.002238] [leak_check] [<ffffffff>]
0xffffffff
2670051 Oct 27 06:32:38 ubuntu kernel: [16964.002242] [leak_check]
----------------------------------------
2670052 Oct 27 06:32:38 ubuntu kernel: [16964.002248] [leak_check] Totals:
2670053 Oct 27 06:32:38 ubuntu kernel: [16964.002251] [leak_check] Allocations:
3
2670054 Oct 27 06:32:38 ubuntu kernel: [16964.002255] [leak_check] Possible
leaks: 1
2670055 Oct 27 06:32:38 ubuntu kernel: [16964.002257] [leak_check] Unallocated
frees: 0
2670056 Oct 27 06:32:38 ubuntu kernel: [16964.002260] [leak_check] ======== end
of LeakCheck report ========
<snip>
As you can see that with reports generated by KEDR like above, it becomes easy
to detect the memory leak and therefore I'm looking at something similar like KEDR
for detecting locking errors in kernel module.

-Amit
[1] http://lxr.linux.no/#linux+v3.6.3/Documentation/lockdep-design.txt