kmemleak - percpu reliability?

kmemleak - percpu reliability?

[Johannes Berg]

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

Re: kmemleak - percpu reliability?

[Catalin Marinas]

Hi,

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

Re: kmemleak - percpu reliability?

[Johannes Berg]

On Wed, 2016-04-27 at 10:38 +0100, Catalin Marinas wrote:
> 
> 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.
> 

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