[2.6.31] Memory leak in SCSI initialization?

[2.6.31] Memory leak in SCSI initialization?

[Tetsuo Handa]

Hello.

I can see below message appears for 15 times in
/sys/kernel/debug/kmemleak after processing /init inside initramfs.

unreferenced object 0xdeadb5c8 (size 32):
  comm "insmod", pid 543, jiffies 4294674766
  backtrace:
    [<c048a22c>] create_object+0x135/0x202
    [<c048a31e>] kmemleak_alloc+0x25/0x49
    [<c04865d9>] kmemleak_alloc_recursive+0x1c/0x22
    [<c0486d33>] __kmalloc+0x6c/0xb9
    [<c04f5675>] kvasprintf+0x2d/0x4a
    [<c04ef5af>] kobject_set_name_vargs+0x21/0x50
    [<c054bbd7>] dev_set_name+0x1a/0x1c
    [<e08dc1b7>] scsi_sysfs_device_initialize+0x8b/0xe4 [scsi_mod]
    [<e08d9bbf>] scsi_alloc_sdev+0x134/0x18f [scsi_mod]
    [<e08d9e7a>] scsi_probe_and_add_lun+0x107/0xa98 [scsi_mod]
    [<e08da946>] __scsi_scan_target+0x70/0x4b1 [scsi_mod]
    [<e08dadbe>] scsi_scan_channel+0x37/0x60 [scsi_mod]
    [<e08dae9f>] scsi_scan_host_selected+0xb8/0xf1 [scsi_mod]
    [<e08daf2c>] do_scsi_scan_host+0x54/0x5d [scsi_mod]
    [<e08db2ef>] scsi_scan_host+0x14d/0x165 [scsi_mod]
    [<e0959771>] mptspi_probe+0x2cd/0x2f8 [mptspi]

Environment is CentOS 5.3 on i686 .
The content of /init is shown below.

--
#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
echo "Loading jbd.ko module"
insmod /lib/jbd.ko 
echo "Loading ext3.ko module"
insmod /lib/ext3.ko 
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko 
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko 
echo "Loading scsi_transport_spi.ko module"
insmod /lib/scsi_transport_spi.ko 
echo "Loading mptbase.ko module"
insmod /lib/mptbase.ko 
echo "Loading mptscsih.ko module"
insmod /lib/mptscsih.ko 
echo "Loading mptspi.ko module"
insmod /lib/mptspi.ko 
echo Waiting for driver initialization.
stabilized --hash --interval 1000 /proc/scsi/scsi
mkblkdevs
echo Scanning and configuring dmraid supported devices
echo Creating root device.
mkrootdev -t ext3 -o noatime,nodiratime,ro sda1
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot
--

This is a different one from the one solved by applying
http://lkml.org/lkml/2009/9/21/384 .

Regards.

Re: [2.6.31] Memory leak in SCSI initialization?

[Kelly Bowa]

* Tetsuo Handa (penguin-kernel@I-love.SAKURA.ne.jp) wrote:
> Hello.
> 
> I can see below message appears for 15 times in
> /sys/kernel/debug/kmemleak after processing /init inside initramfs.
...
Hi Tetsuo,

I can confirm this on 2.6.31-rc9 with following trace:
http://www.tuxedu.org/people/kbpm/bad/scsi-trace

Thanks,
kbpm

Re: [2.6.31] Memory leak in SCSI initialization?

[Xiaotian Feng]

Can this patch fix your leak?

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index c447838..b0d3984 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -318,6 +318,7 @@ out_device_destroy:
        scsi_device_set_state(sdev, SDEV_DEL);
        transport_destroy_device(&sdev->sdev_gendev);
        put_device(&sdev->sdev_gendev);
+       put_device(&sdev->sdev_dev);
 out:
        if (display_failure_msg)
                printk(ALLOC_FAILURE_MSG, __func__);
@@ -958,6 +959,7 @@ static inline void scsi_destroy_sdev(struct
scsi_device *sdev)
                sdev->host->hostt->slave_destroy(sdev);
        transport_destroy_device(&sdev->sdev_gendev);
        put_device(&sdev->sdev_gendev);
+       put_device(&sdev->sdev_dev);
 }

 #ifdef CONFIG_SCSI_LOGGING



On Tue, Sep 22, 2009 at 12:18 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Hello.
>
> I can see below message appears for 15 times in
> /sys/kernel/debug/kmemleak after processing /init inside initramfs.
>
> unreferenced object 0xdeadb5c8 (size 32):
>  comm "insmod", pid 543, jiffies 4294674766
>  backtrace:
>    [<c048a22c>] create_object+0x135/0x202
>    [<c048a31e>] kmemleak_alloc+0x25/0x49
>    [<c04865d9>] kmemleak_alloc_recursive+0x1c/0x22
>    [<c0486d33>] __kmalloc+0x6c/0xb9
>    [<c04f5675>] kvasprintf+0x2d/0x4a
>    [<c04ef5af>] kobject_set_name_vargs+0x21/0x50
>    [<c054bbd7>] dev_set_name+0x1a/0x1c
>    [<e08dc1b7>] scsi_sysfs_device_initialize+0x8b/0xe4 [scsi_mod]
>    [<e08d9bbf>] scsi_alloc_sdev+0x134/0x18f [scsi_mod]
>    [<e08d9e7a>] scsi_probe_and_add_lun+0x107/0xa98 [scsi_mod]
>    [<e08da946>] __scsi_scan_target+0x70/0x4b1 [scsi_mod]
>    [<e08dadbe>] scsi_scan_channel+0x37/0x60 [scsi_mod]
>    [<e08dae9f>] scsi_scan_host_selected+0xb8/0xf1 [scsi_mod]
>    [<e08daf2c>] do_scsi_scan_host+0x54/0x5d [scsi_mod]
>    [<e08db2ef>] scsi_scan_host+0x14d/0x165 [scsi_mod]
>    [<e0959771>] mptspi_probe+0x2cd/0x2f8 [mptspi]
>
> Environment is CentOS 5.3 on i686 .
> The content of /init is shown below.
>
> --
> #!/bin/nash
>
> mount -t proc /proc /proc
> setquiet
> echo Mounting proc filesystem
> echo Mounting sysfs filesystem
> mount -t sysfs /sys /sys
> echo Creating /dev
> mount -o mode=0755 -t tmpfs /dev /dev
> mkdir /dev/pts
> mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
> mkdir /dev/shm
> mkdir /dev/mapper
> echo Creating initial device nodes
> mknod /dev/null c 1 3
> mknod /dev/zero c 1 5
> mknod /dev/systty c 4 0
> mknod /dev/tty c 5 0
> mknod /dev/console c 5 1
> mknod /dev/ptmx c 5 2
> mknod /dev/rtc c 10 135
> mknod /dev/tty0 c 4 0
> mknod /dev/tty1 c 4 1
> mknod /dev/tty2 c 4 2
> mknod /dev/tty3 c 4 3
> mknod /dev/tty4 c 4 4
> mknod /dev/tty5 c 4 5
> mknod /dev/tty6 c 4 6
> mknod /dev/tty7 c 4 7
> mknod /dev/tty8 c 4 8
> mknod /dev/tty9 c 4 9
> mknod /dev/tty10 c 4 10
> mknod /dev/tty11 c 4 11
> mknod /dev/tty12 c 4 12
> mknod /dev/ttyS0 c 4 64
> mknod /dev/ttyS1 c 4 65
> mknod /dev/ttyS2 c 4 66
> mknod /dev/ttyS3 c 4 67
> echo Setting up hotplug.
> hotplug
> echo Creating block device nodes.
> mkblkdevs
> echo "Loading jbd.ko module"
> insmod /lib/jbd.ko
> echo "Loading ext3.ko module"
> insmod /lib/ext3.ko
> echo "Loading scsi_mod.ko module"
> insmod /lib/scsi_mod.ko
> echo "Loading sd_mod.ko module"
> insmod /lib/sd_mod.ko
> echo "Loading scsi_transport_spi.ko module"
> insmod /lib/scsi_transport_spi.ko
> echo "Loading mptbase.ko module"
> insmod /lib/mptbase.ko
> echo "Loading mptscsih.ko module"
> insmod /lib/mptscsih.ko
> echo "Loading mptspi.ko module"
> insmod /lib/mptspi.ko
> echo Waiting for driver initialization.
> stabilized --hash --interval 1000 /proc/scsi/scsi
> mkblkdevs
> echo Scanning and configuring dmraid supported devices
> echo Creating root device.
> mkrootdev -t ext3 -o noatime,nodiratime,ro sda1
> echo Mounting root filesystem.
> mount /sysroot
> echo Setting up other filesystems.
> setuproot
> echo Switching to new root and running init.
> switchroot
> --
>
> This is a different one from the one solved by applying
> http://lkml.org/lkml/2009/9/21/384 .
>
> Regards.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6.31] Memory leak in SCSI initialization?

[Tetsuo Handa]

Hello.

Xiaotian Feng wrote:
> Can this patch fix your leak?
> 
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index c447838..b0d3984 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -318,6 +318,7 @@ out_device_destroy:
>  	scsi_device_set_state(sdev, SDEV_DEL);
>  	transport_destroy_device(&sdev->sdev_gendev);
>  	put_device(&sdev->sdev_gendev);
> +	put_device(&sdev->sdev_dev);
>  out:
>  	if (display_failure_msg)
>  		printk(ALLOC_FAILURE_MSG, __func__);
> @@ -958,6 +959,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
>  		sdev->host->hostt->slave_destroy(sdev);
>  	transport_destroy_device(&sdev->sdev_gendev);
>  	put_device(&sdev->sdev_gendev);
> +	put_device(&sdev->sdev_dev);
>  }
>  
>  #ifdef CONFIG_SCSI_LOGGING

No. I got slab corruption message for 14 times after applying this patch.
Isn't this patch calling put_device(&sdev->sdev_dev); more than needed?

kmemleak: Kernel memory leak detector initialized
kmemleak: Automatic memory scanning thread started
Freeing unused kernel memory: 300k freed
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
SCSI subsystem initialized
Fusion MPT base driver 3.04.10
Copyright (c) 1999-2008 LSI Corporation
Fusion MPT SPI Host driver 3.04.10
mptspi 0000:00:10.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
mptbase: ioc0: Initiating bringup
ioc0: LSI53C1030 B0: Capabilities={Initiator}
scsi0 : ioc0: LSI53C1030 B0, FwRev=00000000h, Ports=1, MaxQ=128, IRQ=17
scsi 0:0:0:0: Direct-Access     VMware,  VMware Virtual S 1.0  PQ: 0 ANSI: 2
 target0:0:0: Beginning Domain Validation
 target0:0:0: Domain Validation skipping write tests
 target0:0:0: Ending Domain Validation
 target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
sd 0:0:0:0: [sda] 41943040 512-byte logical blocks: (21.4 GB/20.0 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Cache data unavailable
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Cache data unavailable
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda:
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<(null)>](0x0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
 sda1
sd 0:0:0:0: [sda] Cache data unavailable
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI disk
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41
Slab corruption: size-1024 start=deb62f48, len=1024
Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
Last user: [<c0486122>](kfree+0x49/0x50)
180: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Single bit error detected. Probably bad RAM.
Run memtest86+ or a similar memory test tool.
Prev obj: start=deb62b30, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 62 6c 6f 63 6b 2f 73 64 61 00 41
010: 43 54 49 4f 4e 3d 61 64 64 00 44 45 56 50 41 54
Next obj: start=deb63360, len=1024
Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
Last user: [<c04efd04>](kobject_uevent_env+0x23b/0x35c)
000: 61 64 64 40 2f 63 6c 61 73 73 2f 73 63 73 69 5f
010: 64 65 76 69 63 65 2f 30 3a 30 3a 30 3a 30 00 41

Re: [2.6.31] Memory leak in SCSI initialization?

[Michael Ellerman]

On Tue, 2009-09-22 at 13:18 +0900, Tetsuo Handa wrote:
> Hello.
> 
> I can see below message appears for 15 times in
> /sys/kernel/debug/kmemleak after processing /init inside initramfs.
> 
> unreferenced object 0xdeadb5c8 (size 32):
>   comm "insmod", pid 543, jiffies 4294674766
>   backtrace:
>     [<c048a22c>] create_object+0x135/0x202
>     [<c048a31e>] kmemleak_alloc+0x25/0x49
>     [<c04865d9>] kmemleak_alloc_recursive+0x1c/0x22
>     [<c0486d33>] __kmalloc+0x6c/0xb9
>     [<c04f5675>] kvasprintf+0x2d/0x4a
>     [<c04ef5af>] kobject_set_name_vargs+0x21/0x50
>     [<c054bbd7>] dev_set_name+0x1a/0x1c
>     [<e08dc1b7>] scsi_sysfs_device_initialize+0x8b/0xe4 [scsi_mod]
>     [<e08d9bbf>] scsi_alloc_sdev+0x134/0x18f [scsi_mod]
>     [<e08d9e7a>] scsi_probe_and_add_lun+0x107/0xa98 [scsi_mod]
>     [<e08da946>] __scsi_scan_target+0x70/0x4b1 [scsi_mod]
>     [<e08dadbe>] scsi_scan_channel+0x37/0x60 [scsi_mod]
>     [<e08dae9f>] scsi_scan_host_selected+0xb8/0xf1 [scsi_mod]
>     [<e08daf2c>] do_scsi_scan_host+0x54/0x5d [scsi_mod]
>     [<e08db2ef>] scsi_scan_host+0x14d/0x165 [scsi_mod]
>     [<e0959771>] mptspi_probe+0x2cd/0x2f8 [mptspi]

I think this will fix it:

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 9ce5c34..284bcbe 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -957,7 +957,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
        if (sdev->host->hostt->slave_destroy)
                sdev->host->hostt->slave_destroy(sdev);
        transport_destroy_device(&sdev->sdev_gendev);
-       put_device(&sdev->sdev_gendev);
+       put_device(&sdev->sdev_dev);
 }
 
 #ifdef CONFIG_SCSI_LOGGING


sdev_dev has class == sdev_class. The release function for sdev_class is
scsi_device_cls_release(), and _that_ does a put on the sdev_gendev.

But someone who groks all that mess, er beauty ;D, should check that
makes sense.

cheers

Re: [2.6.31] Memory leak in SCSI initialization?

[Tetsuo Handa]

Hello.

Michael Ellerman wrote:
> I think this will fix it:
> 
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 9ce5c34..284bcbe 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -957,7 +957,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
>  	if (sdev->host->hostt->slave_destroy)
>  		sdev->host->hostt->slave_destroy(sdev);
>  	transport_destroy_device(&sdev->sdev_gendev);
> -	put_device(&sdev->sdev_gendev);
> +	put_device(&sdev->sdev_dev);
>  }
>  
>  #ifdef CONFIG_SCSI_LOGGING

Yes. This patch solved the memory leak.

Thank you.

Re: [2.6.31] Memory leak in SCSI initialization?

[James Bottomley]

On Tue, 2009-09-22 at 23:13 +1000, Michael Ellerman wrote:
> On Tue, 2009-09-22 at 13:18 +0900, Tetsuo Handa wrote:
> > Hello.
> > 
> > I can see below message appears for 15 times in
> > /sys/kernel/debug/kmemleak after processing /init inside initramfs.
> > 
> > unreferenced object 0xdeadb5c8 (size 32):
> >   comm "insmod", pid 543, jiffies 4294674766
> >   backtrace:
> >     [<c048a22c>] create_object+0x135/0x202
> >     [<c048a31e>] kmemleak_alloc+0x25/0x49
> >     [<c04865d9>] kmemleak_alloc_recursive+0x1c/0x22
> >     [<c0486d33>] __kmalloc+0x6c/0xb9
> >     [<c04f5675>] kvasprintf+0x2d/0x4a
> >     [<c04ef5af>] kobject_set_name_vargs+0x21/0x50
> >     [<c054bbd7>] dev_set_name+0x1a/0x1c
> >     [<e08dc1b7>] scsi_sysfs_device_initialize+0x8b/0xe4 [scsi_mod]
> >     [<e08d9bbf>] scsi_alloc_sdev+0x134/0x18f [scsi_mod]
> >     [<e08d9e7a>] scsi_probe_and_add_lun+0x107/0xa98 [scsi_mod]
> >     [<e08da946>] __scsi_scan_target+0x70/0x4b1 [scsi_mod]
> >     [<e08dadbe>] scsi_scan_channel+0x37/0x60 [scsi_mod]
> >     [<e08dae9f>] scsi_scan_host_selected+0xb8/0xf1 [scsi_mod]
> >     [<e08daf2c>] do_scsi_scan_host+0x54/0x5d [scsi_mod]
> >     [<e08db2ef>] scsi_scan_host+0x14d/0x165 [scsi_mod]
> >     [<e0959771>] mptspi_probe+0x2cd/0x2f8 [mptspi]
> 
> I think this will fix it:
> 
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 9ce5c34..284bcbe 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -957,7 +957,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
>         if (sdev->host->hostt->slave_destroy)
>                 sdev->host->hostt->slave_destroy(sdev);
>         transport_destroy_device(&sdev->sdev_gendev);
> -       put_device(&sdev->sdev_gendev);
> +       put_device(&sdev->sdev_dev);
>  }
>  
>  #ifdef CONFIG_SCSI_LOGGING
> 
> 
> sdev_dev has class == sdev_class. The release function for sdev_class is
> scsi_device_cls_release(), and _that_ does a put on the sdev_gendev.
> 
> But someone who groks all that mess, er beauty ;D, should check that
> makes sense.

The fix is correct, but it's depending on nastily deep magic inside the
scsi sysfs layers.  We have to know at this point that we've allocated
the containing object, parented sdev_dev, named sdev_dev (thus
allocating memory) but won't take a reference on sdev_gendev for
sdev_dev until add time, so doing a final put of sdev_dev also does a
final put of sdev_gendev.

The root cause of the problem is the fact that dev_set_name() now
allocates storage instead of using the original array within the kobj.
That means that the SCSI assumption that if you haven't made the
containing object or any sub objects visible, you can just destroy it
(and its component devices) lock stock and barrel becomes false.

The two ways to fix this naturally seem either to do the get of sdev_dev
at parent time (this is usual) and thus do an extra put of it in
scsi_destroy_sdev() (and all other destruction without add paths) or to
make sure no allocations occur in scsi_sysfs_device_initialize() and
thus we can just garbage collect the entire object without worrying
about subobject allocations.

On the whole, I would favour the latter since it returns us to the
original assumptions, but that would also leave us with unnamed SCSI
devices up until add time, which might be confusing, so let's try the
former.

Can we verify this fixes the memory leak?

James

---
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index c447838..0547a7f 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -317,6 +317,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
 out_device_destroy:
 	scsi_device_set_state(sdev, SDEV_DEL);
 	transport_destroy_device(&sdev->sdev_gendev);
+	put_device(&sdev->sdev_dev);
 	put_device(&sdev->sdev_gendev);
 out:
 	if (display_failure_msg)
@@ -957,6 +958,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
 	if (sdev->host->hostt->slave_destroy)
 		sdev->host->hostt->slave_destroy(sdev);
 	transport_destroy_device(&sdev->sdev_gendev);
+	put_device(&sdev->sdev_dev);
 	put_device(&sdev->sdev_gendev);
 }
 
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index fde5453..5c7eb63 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -864,10 +864,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 		goto clean_device;
 	}
 
-	/* take a reference for the sdev_dev; this is
-	 * released by the sdev_class .release */
-	get_device(&sdev->sdev_gendev);
-
 	/* create queue files, which may be writable, depending on the host */
 	if (sdev->host->hostt->change_queue_depth)
 		error = device_create_file(&sdev->sdev_gendev, &sdev_attr_queue_depth_rw);
@@ -917,6 +913,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 
 	device_del(&sdev->sdev_gendev);
 	transport_destroy_device(&sdev->sdev_gendev);
+	put_device(&sdev->sdev_dev);
 	put_device(&sdev->sdev_gendev);
 
 	return error;
@@ -1065,7 +1062,7 @@ void scsi_sysfs_device_initialize(struct scsi_device *sdev)
 		     sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);
 
 	device_initialize(&sdev->sdev_dev);
-	sdev->sdev_dev.parent = &sdev->sdev_gendev;
+	sdev->sdev_dev.parent = get_device(&sdev->sdev_gendev);
 	sdev->sdev_dev.class = &sdev_class;
 	dev_set_name(&sdev->sdev_dev, "%d:%d:%d:%d",
 		     sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);

Re: [2.6.31] Memory leak in SCSI initialization?

[Tetsuo Handa]

Hello.

James Bottomley wrote:
> Can we verify this fixes the memory leak?
I tested this patch on 2.6.31.1 and verified that
the memory leak was solved by this patch.

Thank you.
> 
> ---
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index c447838..0547a7f 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -317,6 +317,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
>  out_device_destroy:
>  	scsi_device_set_state(sdev, SDEV_DEL);
>  	transport_destroy_device(&sdev->sdev_gendev);
> +	put_device(&sdev->sdev_dev);
>  	put_device(&sdev->sdev_gendev);
>  out:
>  	if (display_failure_msg)
> @@ -957,6 +958,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
>  	if (sdev->host->hostt->slave_destroy)
>  		sdev->host->hostt->slave_destroy(sdev);
>  	transport_destroy_device(&sdev->sdev_gendev);
> +	put_device(&sdev->sdev_dev);
>  	put_device(&sdev->sdev_gendev);
>  }
>  
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index fde5453..5c7eb63 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -864,10 +864,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
>  		goto clean_device;
>  	}
>  
> -	/* take a reference for the sdev_dev; this is
> -	 * released by the sdev_class .release */
> -	get_device(&sdev->sdev_gendev);
> -
>  	/* create queue files, which may be writable, depending on the host */
>  	if (sdev->host->hostt->change_queue_depth)
>  		error = device_create_file(&sdev->sdev_gendev, &sdev_attr_queue_depth_rw);
> @@ -917,6 +913,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
>  
>  	device_del(&sdev->sdev_gendev);
>  	transport_destroy_device(&sdev->sdev_gendev);
> +	put_device(&sdev->sdev_dev);
>  	put_device(&sdev->sdev_gendev);
>  
>  	return error;
> @@ -1065,7 +1062,7 @@ void scsi_sysfs_device_initialize(struct scsi_device *sdev)
>  		     sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);
>  
>  	device_initialize(&sdev->sdev_dev);
> -	sdev->sdev_dev.parent = &sdev->sdev_gendev;
> +	sdev->sdev_dev.parent = get_device(&sdev->sdev_gendev);
>  	sdev->sdev_dev.class = &sdev_class;
>  	dev_set_name(&sdev->sdev_dev, "%d:%d:%d:%d",
>  		     sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);

Re: [2.6.31] Memory leak in SCSI initialization?

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

On Fri, 2009-10-02 at 13:30 -0500, James Bottomley wrote:
> On Tue, 2009-09-22 at 23:13 +1000, Michael Ellerman wrote:
> > On Tue, 2009-09-22 at 13:18 +0900, Tetsuo Handa wrote:
> > > Hello.
> > > 
> > > I can see below message appears for 15 times in
> > > /sys/kernel/debug/kmemleak after processing /init inside initramfs.
> > > 
> > > unreferenced object 0xdeadb5c8 (size 32):
> > >   comm "insmod", pid 543, jiffies 4294674766
> > >   backtrace:
> > >     [<c048a22c>] create_object+0x135/0x202
> > >     [<c048a31e>] kmemleak_alloc+0x25/0x49
> > >     [<c04865d9>] kmemleak_alloc_recursive+0x1c/0x22
> > >     [<c0486d33>] __kmalloc+0x6c/0xb9
> > >     [<c04f5675>] kvasprintf+0x2d/0x4a
> > >     [<c04ef5af>] kobject_set_name_vargs+0x21/0x50
> > >     [<c054bbd7>] dev_set_name+0x1a/0x1c
> > >     [<e08dc1b7>] scsi_sysfs_device_initialize+0x8b/0xe4 [scsi_mod]
> > >     [<e08d9bbf>] scsi_alloc_sdev+0x134/0x18f [scsi_mod]
> > >     [<e08d9e7a>] scsi_probe_and_add_lun+0x107/0xa98 [scsi_mod]
> > >     [<e08da946>] __scsi_scan_target+0x70/0x4b1 [scsi_mod]
> > >     [<e08dadbe>] scsi_scan_channel+0x37/0x60 [scsi_mod]
> > >     [<e08dae9f>] scsi_scan_host_selected+0xb8/0xf1 [scsi_mod]
> > >     [<e08daf2c>] do_scsi_scan_host+0x54/0x5d [scsi_mod]
> > >     [<e08db2ef>] scsi_scan_host+0x14d/0x165 [scsi_mod]
> > >     [<e0959771>] mptspi_probe+0x2cd/0x2f8 [mptspi]
> > 
> > I think this will fix it:
> > 
> > diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> > index 9ce5c34..284bcbe 100644
> > --- a/drivers/scsi/scsi_scan.c
> > +++ b/drivers/scsi/scsi_scan.c
> > @@ -957,7 +957,7 @@ static inline void scsi_destroy_sdev(struct scsi_device *sdev)
> >         if (sdev->host->hostt->slave_destroy)
> >                 sdev->host->hostt->slave_destroy(sdev);
> >         transport_destroy_device(&sdev->sdev_gendev);
> > -       put_device(&sdev->sdev_gendev);
> > +       put_device(&sdev->sdev_dev);
> >  }
> >  
> >  #ifdef CONFIG_SCSI_LOGGING
> > 
> > 
> > sdev_dev has class == sdev_class. The release function for sdev_class is
> > scsi_device_cls_release(), and _that_ does a put on the sdev_gendev.
> > 
> > But someone who groks all that mess, er beauty ;D, should check that
> > makes sense.
> 
> The fix is correct, but it's depending on nastily deep magic inside the
> scsi sysfs layers.

Indeed, thanks for having a better look at it.

I also used CONFIG_DEBUG_KOBJECT to verify that there was only one name
being freed without the patch and two with it - which is a slightly more
direct proof than the memleak output.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]