debug kernel module (memory corruption_

Question

I'm debugging my kernel module, which appears to have a memory corruption, basically a piece of memory allocated by alloc_netdev() for 'net_device' instance has been corrupted.

1) I turned on CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_SLAB, CONFIG_DEBUG_KMEMLEAK in my kernel's .config, however not sure what to expect from kmemleak. Is it supposed to print out a trace dump of suspected memory leaks whenever I read /sys/kernel/debug/kmemleak? Is there a way to reset the statistics/information accumulated by kmemleak? An the most important -- could anyone help to decipher the output, e.g. :

unreferenced object 0xc625e000 (size 2048):
  comm "swapper", pid 1, jiffies 4294937521
  backtrace:
    [<c00c89f0>] create_object+0x11c/0x200
    [<c00c6764>] __kmalloc_track_caller+0x138/0x178
    [<c01d78c0>] __alloc_skb+0x4c/0x100
    [<c01d8490>] dev_alloc_skb+0x18/0x3c
    [<c0198b48>] eth_rx_fill+0xd8/0x3fc
    [<c019ac74>] mv_eth_start_internals+0x30/0xf8
    [<c019c5fc>] mv_eth_start+0x70/0x244
    [<c019c810>] mv_eth_open+0x40/0x64
    [<c01e00f0>] dev_open+0xb4/0x118
    [<c01df788>] dev_change_flags+0x90/0x168
    [<c001a3e4>] ip_auto_config+0x1bc/0xecc
    [<c00212f4>] do_one_initcall+0x5c/0x1bc
    [<c00083d0>] kernel_init+0x8c/0x108
    [<c0022f58>] kernel_thread_exit+0x0/0x8
    [<ffffffff>] 0xffffffff

2) I was also wondering if I could apply some "read-only" attribute on this memory, this way I expect to have Oops generated when someone tries to modify the memory. Does it sound reasonable?

Appreciate any advices, thanks.

Mark

Answer 1

To catch incorrect memory accesses, KAsan or kmemcheck could probably be more useful. Note that Kmemcheck, however, is known to incur a significant which may sometimes be unacceptable, so it is up to you to decide. KASan should be much faster.

1. Concerning kmemleak, its operation is described in detail in the kernel docs.

In short, it is more reliable to execute

echo scan > /sys/kernel/debug/kmemleak

as root to trigger memory analysis immediately before you read /sys/kernel/debug/kmemleak. Sometimes, I found even more reliable to execute the above command twice before reading kmemleak's report.

To "reset" the data collected by kmemleak, you can execute

echo clear > /sys/kernel/debug/kmemleak

The output you have posted means that kmemleak thinks that a memory area 2Kb in size at address 0xc625e000 has not been freed at the time the tool has last analyzed memory. The backtrace specifies where the memory was allocated. "swapper" is the name of the process that has allocated that memory area.

2. As far as setting memory read-only is concerned, this technique is indeed used in some places of the kernel, e.g. to protect the code of the kernel proper and the modules. I cannot give you exact instructions here but the implementation of set_page_attributes() function is a good place to start digging in.

Note that kmemcheck I mentioned above uses a somewhat similar technique to track memory accesses: makes pages "look" like they do not exist so that each access to them causes a page fault, etc. The details are in the kernel docs, as usual.