Re: kmemleak - percpu reliability?

[Catalin Marinas]

Hi,

On 27 April 2016 at 10:00, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> 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.

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