kmemleak - percpu reliability?

Hi,

Yesterday I found the bug fixed by this commit:
https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211.git/commit/?id=e6436be21e77e3659b4ff7e357ab5a8342d132d2

The first case can easily be reproduced by running:

# iw wlan0 interface add wlan0 type monitor

(reusing the name "wlan0" twice, the command should fail)

I tried to see what happens with kmemleak, but for some reason it won't report it even with forced rescan etc.

Am I missing something?

Thanks,
johannes

Hi,

Kmemleak tries to reduce the false positives to the detriment of more false negatives. One way it does this is by having to scan the memory twice and no changes to the leaked object (crc32) should have happened. It also scans the task stacks which is another source of false/stale pointers. The leak may eventually be reported but you can't really be precise on when this would be.

Kmemleak scanning is currently meant as a background thread with minimal disruption (just some overhead). I plan to add a "stopscan" option which invokes stop_machine() and avoids scanning the task stacks. This should be more precise but is aimed at specific test environments (stop_machine() scanning could lock the system for seconds to minutes).

Catalin

:)

Ok, fair enough. I don't remember if I asked it to scan twice, but anyway, I did convince myself separately (with prints) that it was leaked :)

Thanks for the explanation!

johannes