linux-kernel - Re: DRM-related kmalloc-32 memory leak in 2.6.35

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20100927115207.633024b1.akpm@linux-foundation.org>
Date:	Mon, 27 Sep 2010 11:52:07 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Christoph Lameter <cl@...ux.com>, David Airlie <airlied@...ux.ie>,
	David Rientjes <rientjes@...gle.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Linux Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: DRM-related kmalloc-32 memory leak in 2.6.35

On Wed, 25 Aug 2010 15:59:09 -0500
Matt Mackall <mpm@...enic.com> wrote:

> On Tue, 2010-08-24 at 10:37 -0500, Christoph Lameter wrote:
> > On Tue, 24 Aug 2010, Matt Mackall wrote:
> > 
> > > kmalloc-32        1113344 1113344     32  128    1 : tunables    0    0
> > > 0 : slabdata   8698   8698      0
> > >
> > > That's /proc/slabinfo on my laptop with SLUB. It looks like my last
> > > reboot popped me back to 2.6.33 so it may also be old news, but I
> > > couldn't spot any reports with Google.
> > 
> > Boot with "slub_debug" as a kernel parameter
> > 
> > and then do a
> > 
> > cat /sys/kernel/slab/kmalloc-32/alloc_calls
> > 
> > to find the caller allocating the objets.
> 
> Still present in 2.6.35. Appears to be DRM:
> 
>     845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089
> cpus=0-1
> 
> That's after about a minute of uptime. Grows to 100k in about a day.
> 
> dmesg bits:
> [    0.834653] [drm] Initialized drm 1.1.0 20060810
> [    0.834986] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [    0.834995] pci 0000:00:02.0: setting latency timer to 64
> [    1.002572] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
> [    1.002580] [drm] MTRR allocation failed.  Graphics performance may suffer.
> [    1.019880] acpi device:03: registered as cooling_device2
> [    1.021520] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
> [    1.021543] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
> [    1.021855] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
> 
> This is with:
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 03)
> 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 03)
> 

Matt tells me that this (drop-dead box-killing!) bug is still present
in current kernels.  Could someone take a look please?

The code seems very simple, and I couldn't spot a problem.  Probably
this means that I'm even simpler.

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