Possible memory leak via alloc_pid()

From: Catalin Marinas
Date: Wed Jul 08 2009 - 17:40:50 EST


Hi,

There's a kmemleak report of a struct pid allocation in alloc_pid()
which somehow gets lost:

unreferenced object 0xc307aa00 (size 44):
comm "gdm", pid 2734, jiffies 4294902040
backtrace:
[<c01e721a>] create_object+0xfa/0x250
[<c01e73cd>] kmemleak_alloc+0x5d/0x70
[<c01e0ad6>] kmem_cache_alloc+0x156/0x1a0
[<c01552f9>] alloc_pid+0x19/0x350
[<c013e6e0>] copy_process+0x800/0x1230
[<c013f17f>] do_fork+0x6f/0x370
[<c0101986>] sys_clone+0x36/0x40
[<c010319c>] sysenter_do_call+0x12/0x38
[<ffffffff>] 0xffffffff

This is the gdm fork for starting Xorg (with pid 2739). It first
logged me in automatically, after which I logged out and gdm started
another Xorg. The pid structure for the first Xorg is reported as a
leak. The Xorg with pid 2739 is no longer present on my system.

Using gdb vmlinux /proc/kcore shows that the pid->count is 2, so
that's why it probably wasn't freed by put_pid():

(gdb) print ({struct pid}0xc307aa00)
$20 = {count = {counter = 2}, level = 0, tasks = {{first = 0x0}, {
first = 0x0}, {first = 0x0}}, rcu = {next = 0xc24bfd64,
func = 0xc0154e90 <delayed_put_pid>}, numbers = {{nr = 2739,
ns = 0xc0737540, pid_chain = {next = 0x0, pprev = 0x200200}}}}

Note that kmemleak is aware of and scans pid_hash (which was recorded
in kmemleak as a 16KB object).

Regards.

--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/