Dear kmemleak and/or x86 maintainers,

I asked for too much memory. The machine started swapping. I killed the 
hog. Then I found this gem:

unreferenced object 0xffff8800006ea000 (size 8192):
   comm "Xorg", pid 1415, jiffies 4298164697 (age 2433.696s)
   hex dump (first 32 bytes):
     00 00 00 00 00 00 00 00 0f 00 00 00 0f 00 00 00  ................
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   backtrace:
     [<ffffffff813feeb1>] kmemleak_alloc+0x21/0x50
     [<ffffffff8111086b>] kmem_cache_alloc_trace+0xdb/0x1d0
     [<ffffffff81001fbe>] copy_thread+0x1be/0x260
     [<ffffffff81044953>] copy_process+0xee3/0x1520
     [<ffffffff810450d6>] do_fork+0x116/0x350
     [<ffffffff8100a7d3>] sys_clone+0x23/0x30
     [<ffffffff8141c173>] stub_clone+0x13/0x20
     [<ffffffffffffffff>] 0xffffffffffffffff

An identical blurb was reported a year ago as
https://lists.linuxfoundation.org/pipermail/bugme-janitors/2010-October/022194.html
although that thread concludes without resolution. The method of 
triggering it described there, that is enabling the KDE screen saver, 
does not retrigger this for me.

I am running kernel 3.1.3 on x64 with the (as far as I can tell 
completely unrelated) patch
https://lkml.org/lkml/2011/8/19/355

I am surprised by the 'coreness' of these functions viz the fact that I 
am the only one hitting this. Could this be a kmemleak false positive?

With kind regards,

Wouter M. Koolen