search

bootlin / training-materials

Bootlin embedded Linux and kernel training materials
https://bootlin.com/training/
Other
603 stars 179 forks source link

Improve kmemleak lab to make it less cryptic #231

Open Tropicao opened 5 months ago

Tropicao commented 5 months ago

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:

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

lucaceresoli commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.