From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Martin Mokrejs
<mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
Cc: Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: linux-3.7.[1,4]: kmemleak in i801_probe
Date: Wed, 23 Jan 2013 17:42:04 +0100 [thread overview]
Message-ID: <20130123174204.00463f98@endymion.delvare> (raw)
In-Reply-To: <50FFC659.1090402-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
Hi Martin,
On Wed, 23 Jan 2013 12:15:37 +0100, Martin Mokrejs wrote:
> Hi,
> I already reported this to lkml recently with linux-3.7.1 but this is to let you know
> that with 3.7.4 I am still getting this kmemleak reported by the kernel.
I don't read LKML.
> unreferenced object 0xffff88040b614690 (size 256):
> comm "swapper/0", pid 1, jiffies 4294937573 (age 133834.550s)
> hex dump (first 32 bytes):
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
> ff ff ff ff ff ff ff ff 08 7f 5d 82 ff ff ff ff ..........].....
> backtrace:
> [<ffffffff815b4aad>] kmemleak_alloc+0x21/0x3e
> [<ffffffff81110352>] slab_post_alloc_hook+0x28/0x2a
> [<ffffffff8111288a>] __kmalloc+0xf2/0x104
> [<ffffffff81305165>] kzalloc.constprop.14+0xe/0x10
> [<ffffffff813055c6>] device_private_init+0x14/0x63
> [<ffffffff813076a0>] dev_set_drvdata+0x19/0x2f
> [<ffffffff815c4f5e>] i801_probe+0x5e/0x451
> [<ffffffff81280e40>] local_pci_probe+0x39/0x61
> [<ffffffff81281f53>] pci_device_probe+0xc6/0xf3
> [<ffffffff81307c5d>] driver_probe_device+0xa9/0x1c1
> [<ffffffff81307dcf>] __driver_attach+0x5a/0x7e
> [<ffffffff8130650a>] bus_for_each_dev+0x57/0x83
> [<ffffffff81307806>] driver_attach+0x19/0x1b
> [<ffffffff813073d8>] bus_add_driver+0xa8/0x1fa
> [<ffffffff81308241>] driver_register+0x8c/0x106
> [<ffffffff81281b4e>] __pci_register_driver+0x59/0x5d
I am using the i2c-i801 driver, enabled kmemleak, but I don't get this
leak. Did you have to do anything special to get it? Didn't you get a
similar leak with older kernels? Do you get a similar leak (with
reference to dev_set_drvdata)?
I can see that dev_set_drvdata may allocate memory (which I didn't
know) and I admit I don't see where it gets released, however this is
all happening in the driver core and isn't specific to the i2c-i801
driver, so if there really is a leak there, you should see it in all
drivers.
--
Jean Delvare
next prev parent reply other threads:[~2013-01-23 16:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 11:15 linux-3.7.[1,4]: kmemleak in i801_probe Martin Mokrejs
[not found] ` <50FFC659.1090402-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
2013-01-23 16:42 ` Jean Delvare [this message]
[not found] ` <20130123174204.00463f98-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2013-01-23 17:35 ` Martin Mokrejs
2013-12-23 9:39 ` [PATCH] i2c: i801: fix memleak on probe error Peter Wu
[not found] ` <1387791578-1372-1-git-send-email-lekensteyn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-12-23 10:43 ` Peter Wu
2013-12-23 10:51 ` Martin Mokrejs
[not found] ` <52B815A0.1060609-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org>
2013-12-23 15:49 ` How should dev_[gs]et_drvdata be used? (was: Re: [PATCH] i2c: i801: fix memleak on probe error) Peter Wu
2013-12-23 17:37 ` Alex Williamson
[not found] ` <1387820241.30327.105.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-12-24 0:18 ` How should dev_[gs]et_drvdata be used? Peter Wu
2013-12-24 1:51 ` Alex Williamson
[not found] ` <1387849869.30327.201.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-12-24 9:44 ` Peter Wu
2014-01-08 13:28 ` Jean Delvare
[not found] ` <20140108142849.3993341c-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2014-11-25 21:14 ` Uwe Kleine-König
[not found] ` <20141125211432.GA6008-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-11-28 13:48 ` Jean Delvare
[not found] ` <20141128144813.3e6fd8d9-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2014-11-28 14:04 ` Uwe Kleine-König
2014-01-08 9:05 ` [PATCH] i2c: i801: fix memleak on probe error Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130123174204.00463f98@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mmokrejs-08dBlVkRsZWoiTQjSSYKZesEoJ4y9sgM@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).