Improve kmemleak lab to make it less cryptic

[Tropicao]

Current kmemleak lab often leads trainees to get lost in details unrelated to the key point of the lab, because of the place of the leak: it can be detected by kmemleak only after module removal, and so symbols are not present anymore in the report :

unreferenced object 0xc3c22600 (size 256):
  comm "kworker/1:1", pid 27, jiffies 4294939650 (age 224.040s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<3f52ba5d>] __kmem_cache_alloc_node+0x1d0/0x308
    [<003a3fac>] kmalloc_trace+0x30/0x60
    [<ae2c1826>] 0xbf000068
    [<bd283327>] process_one_work+0x20c/0x618
    [<476487ee>] worker_thread+0x1e8/0x4ac
    [<98f285dd>] kthread+0x110/0x130
    [<964b9691>] ret_from_fork+0x14/0x28

It is still possible to get the relevant info out of the raw address:

• (hackish way) one can either reload the module, and reprint the kmemleak report (hoping it will be loaded at the exact same place as when the leak has happened):

unreferenced object 0xc3c22600 (size 256):
  comm "kworker/1:1", pid 27, jiffies 4294939650 (age 195.540s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<3f52ba5d>] __kmem_cache_alloc_node+0x1d0/0x308
    [<003a3fac>] kmalloc_trace+0x30/0x60
    [<ae2c1826>] my_work_func+0x68/0xac [kmemleak_test]
    [<bd283327>] process_one_work+0x20c/0x618
    [<476487ee>] worker_thread+0x1e8/0x4ac
    [<98f285dd>] kthread+0x110/0x130
    [<964b9691>] ret_from_fork+0x14/0x28

• or take note about where the module has been loaded while it i still inserted (thanks to /proc/modules), substract it to raw address from the report, and feed the result to faddr2line

While it works, those steps are an additional burden for trainees and add confusion to the initial topic.

A better way to handle this would be to ensure that the leak we are searching for

• occurs at runtime and can be detected while the module is still inserted
• is still composed of multiple kind of leaks

[lucaceresoli]

What do you mean by "is still composed of multiple kind of leaks"?

Also, I agree we can improve this, but knowing how to compute the address in a module is useful, so it would be nice to keep it somehow.

[Tropicao]

What do you mean by "is still composed of multiple kind of leaks"?

I mean: keeping multiple sources of leaks so trainees still have to investigate enough to get rid of leaks (we have currently three different leak "sources" in the lab)

Also, I agree we can improve this, but knowing how to compute the address in a module is useful, so it would be nice to keep it somehow.

Hmmm, indeed it is a nice knowledge to have. My main concern is that during training, I see that participants use quite a lot of time and get confused by this part, not really managing to get a clear picture of the process (and even with hints in the labs instructions), at the expense of the rest of the labs. But maybe it is more of a personal experience/personal feeling, and the issue is more around total volume for the kernel lab then ?

[lucaceresoli]

What do you mean by "is still composed of multiple kind of leaks"?

I mean: keeping multiple sources of leaks so trainees still have to investigate enough to get rid of leaks (we have currently three different leak "sources" in the lab)

OK, got it. I agree on this.

Also, I agree we can improve this, but knowing how to compute the address in a module is useful, so it would be nice to keep it somehow.

Hmmm, indeed it is a nice knowledge to have. My main concern is that during training, I see that participants use quite a lot of time and get confused by this part, not really managing to get a clear picture of the process (and even with hints in the labs instructions), at the expense of the rest of the labs. But maybe it is more of a personal experience/personal feeling, and the issue is more around total volume for the kernel lab then ?

I cannot comment about onsite trainings as I haven't done any so far, so I trust you.

About the kernel lab size, I agree it is very long and intensive.
What about just splitting it? One lab after each section? It think it would help both having some "variation" in the trainings and in have better "brain locality" between the lecture content and the corresponding lab.