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 |
||
Created attachment 26039 [details]
i915 gem memleak patch
Please try this patch (In reply to comment #2) > Please try this patch Doesn't help. Created attachment 26092 [details]
allocated cache object should be returned to cache in case of error
Could you please try attached fix.
(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 Ooh, a memory leak. Does this still happen with 2.6.35-rc6? (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 Created attachment 27242 [details]
Fix idr memleak.
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... 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)
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. (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. |
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