From: Guenter Roeck <linux@roeck-us.net>
To: John Garry <john.garry@huawei.com>
Cc: wim@linux-watchdog.org, linux-watchdog@vger.kernel.org
Subject: Re: [report of possible bug] watchdog memory leak
Date: Wed, 7 Jul 2021 09:11:57 -0700 [thread overview]
Message-ID: <20210707161157.GA1454516@roeck-us.net> (raw)
In-Reply-To: <93808c2b-2246-767d-a2d5-cb2e8b1a99c0@huawei.com>
On Wed, Jul 07, 2021 at 01:38:32PM +0100, John Garry wrote:
> Hi guys,
>
> Just a heads up in case it's a real issue - I was developing based on Linus'
> tree at 79160a603bdb, and with KMEMLEAK and DEBUG_TEST_DRIVER_REMOVE configs
> enabled, I get these warns:
>
DEBUG_TEST_DRIVER_REMOVE does odd things, which may well interfer
with reference counting. I don't think this is a spurious issue
(and I have no idea if it is a real issue), but at least for my
part I don't plan to spend any time trying to track this down.
Others, please feel free to jump in.
Thanks,
Guenter
> root@(none)$ [ 859.608780] kmemleak: 3 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
> [ 859.608780] kmemleak: 3 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
>
> root@(none)$ more /sys/kernel/debug/kmemleak
> unreferenced object 0xffff0020f9810800 (size 1024):
> comm "swapper/0", pid 1, jiffies 4294929730 (age 1071.904s)
> hex dump (first 32 bytes):
> 80 89 48 f8 20 00 ff ff 08 08 81 f9 20 00 ff ff ..H. ....... ...
> 08 08 81 f9 20 00 ff ff 00 00 00 00 00 00 00 00 .... ...........
> backtrace:
> [<(____ptrval____)>] slab_post_alloc_hook+0x9c/0x270
> [<(____ptrval____)>] kmem_cache_alloc+0x198/0x2e0
> [<(____ptrval____)>] watchdog_dev_register+0x38/0x428
> [<(____ptrval____)>] __watchdog_register_device+0x13c/0x400
> [<(____ptrval____)>] watchdog_register_device+0x9c/0x108
> [<(____ptrval____)>] devm_watchdog_register_device+0x50/0xe0
> [<(____ptrval____)>] sbsa_gwdt_probe+0x278/0x488
> [<(____ptrval____)>] platform_probe+0x8c/0x108
> [<(____ptrval____)>] really_probe+0x130/0x558
> [<(____ptrval____)>] __driver_probe_device+0xb8/0x130
> [<(____ptrval____)>] driver_probe_device+0x60/0x150
> [<(____ptrval____)>] __driver_attach+0xa0/0x160
> [<(____ptrval____)>] bus_for_each_dev+0xec/0x160
> [<(____ptrval____)>] driver_attach+0x34/0x48
> [<(____ptrval____)>] bus_add_driver+0x1b8/0x2c0
> [<(____ptrval____)>] driver_register+0xc0/0x1e0
> unreferenced object 0xffff0020f8488980 (size 64):
> comm "swapper/0", pid 1, jiffies 4294929730 (age 1071.904s)
> hex dump (first 32 bytes):
> 77 61 74 63 68 64 6f 67 30 00 00 00 00 00 00 00 watchdog0.......
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<(____ptrval____)>] slab_post_alloc_hook+0x9c/0x270
> [<(____ptrval____)>] __kmalloc_track_caller+0x190/0x2d0
> [<(____ptrval____)>] kvasprintf+0xe4/0x1a0
> [<(____ptrval____)>] kvasprintf_const+0xcc/0x178
> [<(____ptrval____)>] kobject_set_name_vargs+0x54/0xf0
> [<(____ptrval____)>] dev_set_name+0xa8/0xd8
> [<(____ptrval____)>] watchdog_dev_register+0x154/0x428
> [<(____ptrval____)>] __watchdog_register_device+0x13c/0x400
> [<(____ptrval____)>] watchdog_register_device+0x9c/0x108
> [<(____ptrval____)>] devm_watchdog_register_device+0x50/0xe0
> [<(____ptrval____)>] sbsa_gwdt_probe+0x278/0x488
> [<(____ptrval____)>] platform_probe+0x8c/0x108
> [<(____ptrval____)>] really_probe+0x130/0x558
> [<(____ptrval____)>] __driver_probe_device+0xb8/0x130
> [<(____ptrval____)>] driver_probe_device+0x60/0x150
> [<(____ptrval____)>] __driver_attach+0xa0/0x160
> unreferenced object 0xffff00208f9b6000 (size 256):
> comm "swapper/0", pid 1, jiffies 4294929730 (age 1071.904s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 08 60 9b 8f 20 00 ff ff .........`.. ...
> 08 60 9b 8f 20 00 ff ff f8 47 b2 10 00 80 ff ff .`.. ....G......
> backtrace:
> [<(____ptrval____)>] slab_post_alloc_hook+0x9c/0x270
> [<(____ptrval____)>] kmem_cache_alloc+0x198/0x2e0
> [<(____ptrval____)>] device_add+0x354/0xcf0
> [<(____ptrval____)>] cdev_device_add+0x74/0xc0
> [<(____ptrval____)>] watchdog_dev_register+0x1e0/0x428
> [<(____ptrval____)>] __watchdog_register_device+0x13c/0x400
> [<(____ptrval____)>] watchdog_register_device+0x9c/0x108
> [<(____ptrval____)>] devm_watchdog_register_device+0x50/0xe0
> [<(____ptrval____)>] sbsa_gwdt_probe+0x278/0x488
> [<(____ptrval____)>] platform_probe+0x8c/0x108
> [<(____ptrval____)>] really_probe+0x130/0x558
> [<(____ptrval____)>] __driver_probe_device+0xb8/0x130
> [<(____ptrval____)>] driver_probe_device+0x60/0x150
> [<(____ptrval____)>] __driver_attach+0xa0/0x160
> [<(____ptrval____)>] bus_for_each_dev+0xec/0x160
> [<(____ptrval____)>] driver_attach+0x34/0x48
> root@(none)$
> root@(none)$
> root@(none)$
>
> I didn't see a report elsewhere. Maybe just a transient issue on Linus'
> tree.
>
> Thanks,
> John
prev parent reply other threads:[~2021-07-07 16:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 12:38 [report of possible bug] watchdog memory leak John Garry
2021-07-07 16:11 ` Guenter Roeck [this message]
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=20210707161157.GA1454516@roeck-us.net \
--to=linux@roeck-us.net \
--cc=john.garry@huawei.com \
--cc=linux-watchdog@vger.kernel.org \
--cc=wim@linux-watchdog.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).