lkml.org 
[lkml]   [2009]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectPossible memory leak via inotify_add_watch
From
Hi Eric,

I'm getting a few kmemleak reports like the one below (it may as well
be just a false positive). All of these allocations happened during
udevd.

unreferenced object 0xc399fd80 (size 84):
comm "udevd", pid 879, jiffies 4294897228
backtrace:
[<c01e0c3a>] create_object+0xfa/0x250
[<c01e1e7d>] kmemleak_alloc+0x5d/0x70
[<c01dac1b>] kmem_cache_alloc+0x14b/0x190
[<c0213800>] sys_inotify_add_watch+0xc0/0x2a0
[<c010300c>] sysenter_do_call+0x12/0x38
[<ffffffff>] 0xffffffff

Printing this object with gdb on /proc/kcore shows:

(gdb) print {struct inotify_inode_mark_entry}0xc399fd80
$2 = {fsn_entry = {mask = 134250504, refcnt = {counter = 1}, inode = 0x0,
group = 0x0, i_list = {next = 0x0, pprev = 0x0}, g_list = {
next = 0xc399fd98, prev = 0xc399fd98}, lock = {raw_lock = {
slock = 1028}, magic = 3735899821, owner_cpu = 4294967295,
owner = 0xffffffff, dep_map = {key = 0xc0d3e59c, class_cache = 0x0,
name = 0xc068413d "&entry->lock"}}, free_i_list = {next = 0x6b6b6b6b,
prev = 0x6b6b6b6b}, free_g_list = {next = 0x6b6b6b6b,
prev = 0x6b6b6b6b}, free_mark = 0xc0213720 <inotify_free_mark>}, wd = 28}

It seems that is was freed via fsnotify_destroy_mark_by_entry() since
group and inode members are NULL and it was removed from any list. The
fsn_entry.refcnt, however, is still 1. Kmemleak cannot find any
pointer to this object (though it doesn't track alloc_pages memory
blocks).

Thanks.

--
Catalin


\
 
 \ /
  Last update: 2009-07-07 00:07    [W:0.058 / U:1.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site