Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1388817 > unrolled thread

kmemleak - percpu reliability?

Back to article view | Back to linux.kernel

Contents

  kmemleak - percpu reliability? Johannes Berg <johannes@sipsolutions.net> - 2016-04-27 11:10 +0200
    Re: kmemleak - percpu reliability? Catalin Marinas <catalin.marinas@arm.com> - 2016-04-27 11:40 +0200
      Re: kmemleak - percpu reliability? Johannes Berg <johannes@sipsolutions.net> - 2016-04-27 11:50 +0200

#1388817 — 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

[toc] | [next] | [standalone]

#1388835

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

[toc] | [prev] | [next] | [standalone]

#1388853

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web