From: John Garry <john.garry@huawei.com>
To: <wim@linux-watchdog.org>, Guenter Roeck <linux@roeck-us.net>,
<linux-watchdog@vger.kernel.org>
Subject: [report of possible bug] watchdog memory leak
Date: Wed, 7 Jul 2021 13:38:32 +0100 [thread overview]
Message-ID: <93808c2b-2246-767d-a2d5-cb2e8b1a99c0@huawei.com> (raw)
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:
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
next reply other threads:[~2021-07-07 12:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 12:38 John Garry [this message]
2021-07-07 16:11 ` [report of possible bug] watchdog memory leak Guenter Roeck
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=93808c2b-2246-767d-a2d5-cb2e8b1a99c0@huawei.com \
--to=john.garry@huawei.com \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--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).