Messages in this thread | | | From | Catalin Marinas <> | Date | Wed, 27 Apr 2016 10:38:41 +0100 | Subject | Re: kmemleak - percpu reliability? |
| |
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
| |