mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
To: Jean Delvare <khali@linux-fr.org>
Cc: Linux I2C <linux-i2c@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-3.7.[1,4]: kmemleak in i801_probe
Date: Wed, 23 Jan 2013 18:35:57 +0100	[thread overview]
Message-ID: <51001F7D.6070905@fold.natur.cuni.cz> (raw)
In-Reply-To: <20130123174204.00463f98@endymion.delvare>

Hi Jean,

Jean Delvare wrote:
> 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

Based on the dmesg timestamp I think I just logged in through xdm. Eh.
Actually, xdm crashes for me, I have to do in the framebuffer VT console:

root # /etc/init.d/xdm stop
user $ startx

and happily use my X. I have a bugreport opened at https://bugs.freedesktop.org/show_bug.cgi?id=56608
but I doubt it is related to i2c_801 driver. But it is not clear
why I cannot just use xdm but can always start X11 via startx.
And actually, rarely, but without reinstalling my kernel or x11
server or drivers, I sometimes (1/20 attempts?) I can login through xdm. But
comparing Xorg.log files from successful xdm login against those unsuccessful
did not help so far. Only reordered items, probably due to autoconfig.
So, I don't think it helps you with isolating the i2c_801 driver memleak.

> similar leak with older kernels? Do you get a similar leak (with
> reference to dev_set_drvdata)?

With 3.7.1 I was getting same stacktrace:

unreferenced object 0xffff88040b1c5230 (size 256):
  comm "swapper/0", pid 1, jiffies 4294937570 (age 182492.630s)
  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 38 3f 5d 82 ff ff ff ff  ........8?].....
  backtrace:
    [<ffffffff815b1dbd>] kmemleak_alloc+0x21/0x3e
    [<ffffffff81110536>] slab_post_alloc_hook+0x28/0x2a
    [<ffffffff81112a6e>] __kmalloc+0xf2/0x104
    [<ffffffff81302bd5>] kzalloc.constprop.14+0xe/0x10
    [<ffffffff81303036>] device_private_init+0x14/0x63
    [<ffffffff81305110>] dev_set_drvdata+0x19/0x2f
    [<ffffffff815c1ed4>] i801_probe+0x5e/0x451
    [<ffffffff81280fb3>] local_pci_probe+0x5b/0xa2
    [<ffffffff81282074>] pci_device_probe+0xc8/0xf7
    [<ffffffff813056cd>] driver_probe_device+0xa9/0x1c1
    [<ffffffff8130583f>] __driver_attach+0x5a/0x7e
    [<ffffffff81303f7a>] bus_for_each_dev+0x57/0x83
    [<ffffffff81305276>] driver_attach+0x19/0x1b
    [<ffffffff81304e48>] bus_add_driver+0xa8/0x1fa
    [<ffffffff81305cb1>] driver_register+0x8c/0x106
    [<ffffffff81281c6d>] __pci_register_driver+0x5a/0x5e

Before 3.7.1 I did not use kmemleak detector. while searching my older emails/reports
I found only that I loaded in the past both drivers (on a 2.6.32.59 kernel):

Mar 26 11:21:55 vostro kernel: i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Mar 26 11:21:55 vostro kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver


And here the relevant line from lspci from that time:
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)

00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
        Subsystem: Dell Device 04b3
        Flags: medium devsel, IRQ 18
        Memory at f7f05000 (64-bit, non-prefetchable) [size=256]
        I/O ports at f040 [size=32]
        Kernel modules: i2c-i801


I don't think this will help you now. :(


> 
> 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.

I am not a kernel developer at all but maybe that little bit points out that the
kmemleak was reported when I was pulling in/out my external USB drives?

Martin

  reply	other threads:[~2013-01-23 17:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23 11:15 Martin Mokrejs
2013-01-23 16:42 ` Jean Delvare
2013-01-23 17:35   ` Martin Mokrejs [this message]
2013-12-23  9:39   ` [PATCH] i2c: i801: fix memleak on probe error Peter Wu
2013-12-23 10:43     ` Peter Wu
2013-12-23 10:51       ` Martin Mokrejs
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
2013-12-24  0:18             ` How should dev_[gs]et_drvdata be used? Peter Wu
2013-12-24  1:51               ` Alex Williamson
2013-12-24  9:44                 ` Peter Wu
2014-01-08 13:28               ` Jean Delvare
2014-11-25 21:14                 ` Uwe Kleine-König
2014-11-28 13:48                   ` Jean Delvare
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=51001F7D.6070905@fold.natur.cuni.cz \
    --to=mmokrejs@fold.natur.cuni.cz \
    --cc=khali@linux-fr.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®