Bug 15803

Summary: kmemleak with intel graphic i915 (GM45 chip set)
Product: Drivers Reporter: Toralf Förster (toralf.foerster)
Component: Video(DRI - Intel)Assignee: Chris Wilson (chris)
Status: RESOLVED CODE_FIX    
Severity: normal CC: jbarnes, kirjanov
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.34-rc4 Subsystem:
Regression: No Bisected commit-id:
Attachments: i915 gem memleak patch
allocated cache object should be returned to cache in case of error
Fix idr memleak.
cp /sys/kernel/debug/kmemleak kmemleak

Description Toralf Förster 2010-04-17 19:00:23 UTC
Hello,

I get this kmemleak, if I start the KDE 4.4.2 KInfocenter and click at the"OpenGL" item :

tfoerste@n22 ~ $ cat /sys/kernel/debug/kmemleak 
unreferenced object 0xc8a81084 (size 148):
  comm "kinfocenter", pid 5458, jiffies 5449359 (age 1152.902s)
  hex dump (first 32 bytes):
    04 00 00 00 00 00 00 00 00 00 00 00 40 46 29 c4  ............@F).
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<c122caed>] kmemleak_alloc+0x3d/0x60
    [<c109c137>] kmem_cache_alloc+0xa7/0xe0
    [<c112286f>] idr_pre_get+0x4f/0x70
    [<f8182fc4>] drm_gem_handle_create+0x24/0x90 [drm]
    [<f8492932>] i915_gem_create_ioctl+0x52/0x90 [i915]
    [<f81814ec>] drm_ioctl+0x2bc/0x450 [drm]
    [<c10aeea8>] vfs_ioctl+0x28/0xb0
    [<c10af06a>] do_vfs_ioctl+0x6a/0x5e0
    [<c10af619>] sys_ioctl+0x39/0x70
    [<c1002cd7>] sysenter_do_call+0x12/0x26
    [<ffffffff>] 0xffffffff


I've a stable Gentoo system at Thinkpad T400 w/ Intel GM45 Express chip set, xorg-server 1.7.6, intel driver 2.11, mesa 7.7.1
Comment 1 Denis Kirjanov 2010-04-17 19:58:39 UTC
Created attachment 26039 [details]
i915 gem memleak patch
Comment 2 Denis Kirjanov 2010-04-17 20:00:15 UTC
Please try this patch
Comment 3 Toralf Förster 2010-04-18 09:31:44 UTC
(In reply to comment #2)
> Please try this patch
Doesn't help.
Comment 4 Denis Kirjanov 2010-04-22 08:28:18 UTC
Created attachment 26092 [details]
allocated cache object should be returned to cache in case of error

Could you please try attached fix.
Comment 5 Toralf Förster 2010-04-22 13:40:37 UTC
(In reply to comment #4)
> Could you please try attached fix.
tried this patch alone and applied together w/ the other patch onto current git sources - no success
Comment 6 Jesse Barnes 2010-07-23 20:04:16 UTC
Ooh, a memory leak.  Does this still happen with 2.6.35-rc6?
Comment 7 Toralf Förster 2010-07-24 10:16:58 UTC
(In reply to comment #6)
> Ooh, a memory leak.  Does this still happen with 2.6.35-rc6?

tfoerste@n22 ~/devel/linux-2.6 $ git describe
v2.6.35-rc6-19-g86c65a7

tfoerste@n22 ~/devel/linux-2.6 $ cat /sys/kernel/debug/kmemleak 
unreferenced object 0xe11f0aec (size 148):
  comm "kinfocenter", pid 12398, jiffies 349798 (age 873.783s)
  hex dump (first 32 bytes):
    04 00 00 00 00 00 00 00 00 00 00 00 40 3d 31 e1  ............@=1.
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<c122f6d7>] kmemleak_alloc+0x27/0x50
    [<c109c4cf>] kmem_cache_alloc+0x9f/0xe0
    [<c1123e14>] idr_pre_get+0x54/0x80
    [<f89ddbc4>] drm_gem_handle_create+0x24/0x90 [drm]
    [<f8b28f02>] i915_gem_create_ioctl+0x52/0x90 [i915]
    [<f89dc081>] drm_ioctl+0x1a1/0x3f0 [drm]
    [<c10aec8d>] vfs_ioctl+0x2d/0xc0
    [<c10aee6a>] do_vfs_ioctl+0x6a/0x590
    [<c10af3c9>] sys_ioctl+0x39/0x60
    [<c1002d97>] sysenter_do_call+0x12/0x26
    [<ffffffff>] 0xffffffff
Comment 8 Chris Wilson 2010-07-24 21:30:05 UTC
Created attachment 27242 [details]
Fix idr memleak.
Comment 9 Chris Wilson 2010-07-24 21:32:47 UTC
The first patch was partially correct, and the second not.

The first is quite scary in that it implies we should be leaking lots of object, yet we do not appear to be...
Comment 10 Toralf Förster 2010-08-03 10:59:16 UTC
Created attachment 27331 [details]
cp /sys/kernel/debug/kmemleak kmemleak

FWIW here are the current content w/ kernel 2.6.35 after an uptime of 2 3/4 hours, reported kmemleaks are connected to the KDE screen saver.

tfoerste@n22 ~ $ xrandr
Screen 0: minimum 320 x 200, current 1440 x 1924, maximum 8192 x 8192
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 340mm x 270mm
   1280x1024      75.0*+   60.0  
   1152x864       75.0  
   1024x768       75.1     72.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
LVDS1 connected 1440x900+0+1024 (normal left inverted right x axis y axis) 303mm x 190mm
   1440x900       60.0*+   50.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
Comment 11 Chris Wilson 2010-08-06 10:04:06 UTC
commit ddd3d069c08bb1ba83aa4d522fc1360ce4afc270
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Jul 24 22:28:25 2010 +0100

    drm: Free the idr layers before calling idr_destroy()
    
    /* A typical clean-up sequence for objects stored in an idr tree, will
     * use idr_for_each() to free all objects, if necessary, then
     * idr_remove_all() to remove all ids, and idr_destroy() to free
     * up the cached idr_layers.
     */
    
    We were missing the vital idr_rmove_all() step and so were leaking
    the used layers for every dri client:
    
    unreferenced object 0xf32133c0 (size 148):
      comm "plymouthd", pid 131, jiffies 4294678490 (age 2308.030s)
      hex dump (first 32 bytes):
        04 00 00 00 00 00 00 00 00 00 00 00 00 40 19 f3  .............@..
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<c04e5657>] create_object+0x124/0x1f1
        [<c07cf100>] kmemleak_alloc+0x4c/0x90
        [<c04db6a9>] kmem_cache_alloc+0xee/0x13c
        [<c05c3d25>] idr_pre_get+0x24/0x61
        [<f8315c9c>] drm_gem_handle_create+0x27/0x7f [drm]
        [<f89925b2>] i915_gem_create_ioctl+0x4f/0x71 [i915]
        [<f83148ac>] drm_ioctl+0x272/0x356 [drm]
        [<c04f27c4>] vfs_ioctl+0x33/0x91
        [<c04f31cf>] do_vfs_ioctl+0x46b/0x496
        [<c04f3240>] sys_ioctl+0x46/0x66
        [<c040325f>] sysenter_do_call+0x12/0x38
        [<ffffffff>] 0xffffffff
    
    Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15803
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

There's a second patch to reduce the false-positives, but this is the fix now upstream.
Comment 12 Toralf Förster 2010-09-10 13:10:05 UTC
(In reply to comment #11)
> There's a second patch to reduce the false-positives, but this is the fix now
> upstream.
Pls could you give me that commit id ? I've patched my 2.6.35.4 vanilla kernel but today I got again 13x times the (false positive ?) reported kmemleak.