On Sat, Jan 23, 2016 at 10:46 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Sat, Jan 23, 2016 at 7:40 PM, Willy Tarreau <w...@1wt.eu> wrote: >> On Sat, Jan 23, 2016 at 07:14:33PM +0100, Dmitry Vyukov wrote: >>> I've attached my .config. >>> Also run this program in a parallel loop. I think it's leaking not >>> every time, probably some race is involved. >> >> Thank you. Just in order to confirm, am I supposed to see the >> messages you quoted in dmesg ? > > > I think the simplest way to confirm that you can reproduce it locally > is to check /proc/slabinfo. When I run this program in a parallel > loop, number of objects in pid cache was constantly growing: > > # cat /proc/slabinfo | grep pid > pid 297 532 576 28 4 : tunables 0 0 > 0 : slabdata 19 19 0 > ... > pid 412 532 576 28 4 : tunables 0 0 > 0 : slabdata 19 19 0 > ... > pid 1107 1176 576 28 4 : tunables 0 0 > 0 : slabdata 42 42 0 > ... > pid 1545 1652 576 28 4 : tunables 0 0 > 0 : slabdata 59 59 0 > > > If you want to use kmemleak, then you need to run this program in a > parallel loop for some time, then stop it and then: > > $ echo scan > /sys/kernel/debug/kmemleak > $ cat /sys/kernel/debug/kmemleak > > If kmemleak has detected any leaks, cat will show them. I noticed that > kmemleak can delay leaks with significant delay, so usually I do scan > at least 5 times.
Note that kmemleak is not needed. Just run a normal kernel (eventually using slab_nomerge=1 boot cmd to make sure 'pid' slab is not shared) It seems that bug is rather old, as linux-4.0 has it.
