* [PATCH] workqueue: fix a memory leak in wq->lock_name
@ 2019-03-07 0:27 Qian Cai
2019-03-09 14:43 ` [tip:locking/urgent] workqueue, lockdep: Fix " tip-bot for Qian Cai
0 siblings, 1 reply; 2+ messages in thread
From: Qian Cai @ 2019-03-07 0:27 UTC (permalink / raw)
To: tj, jiangshanlai
Cc: peterz, mingo, will.deacon, bvanassche, catalin.marinas,
linux-kernel, Qian Cai
The commit 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
workqueues") introduced a memory leak as wq_free_lockdep() calls
kfree(wq->lock_name) but wq_init_lockdep() does not point wq->lock_name
to the newly allocated slab object. This can be reproduced by running
LTP fallocate04 followed by oom01 tests.
unreferenced object 0xc0000005876384d8 (size 64):
comm "fallocate04", pid 26972, jiffies 4297139141 (age 40370.480s)
hex dump (first 32 bytes):
28 77 71 5f 63 6f 6d 70 6c 65 74 69 6f 6e 29 65 (wq_completion)e
78 74 34 2d 72 73 76 2d 63 6f 6e 76 65 72 73 69 xt4-rsv-conversi
backtrace:
[<00000000cb452883>] kvasprintf+0x6c/0xe0
[<000000004654ddac>] kasprintf+0x34/0x60
[<000000001c68f311>] alloc_workqueue+0x1f8/0x6ac
[<0000000003c2ad83>] ext4_fill_super+0x23d4/0x3c80 [ext4]
[<0000000006610538>] mount_bdev+0x25c/0x290
[<00000000bcf955ec>] ext4_mount+0x28/0x50 [ext4]
[<0000000016e08fd3>] legacy_get_tree+0x4c/0xb0
[<0000000042b6a5fc>] vfs_get_tree+0x6c/0x190
[<00000000268ab022>] do_mount+0xb9c/0x1100
[<00000000698e6898>] ksys_mount+0x158/0x180
[<0000000064e391fd>] sys_mount+0x20/0x30
[<00000000ba378f12>] system_call+0x5c/0x70
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for workqueues")
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Qian Cai <cai@lca.pw>
---
kernel/workqueue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index e163e7a7f5e5..ade0d47ec086 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3348,6 +3348,8 @@ static void wq_init_lockdep(struct workqueue_struct *wq)
lock_name = kasprintf(GFP_KERNEL, "%s%s", "(wq_completion)", wq->name);
if (!lock_name)
lock_name = wq->name;
+
+ wq->lock_name = lock_name;
lockdep_init_map(&wq->lockdep_map, lock_name, &wq->key, 0);
}
--
2.17.2 (Apple Git-113)
^ permalink raw reply related [flat|nested] 2+ messages in thread
* [tip:locking/urgent] workqueue, lockdep: Fix a memory leak in wq->lock_name
2019-03-07 0:27 [PATCH] workqueue: fix a memory leak in wq->lock_name Qian Cai
@ 2019-03-09 14:43 ` tip-bot for Qian Cai
0 siblings, 0 replies; 2+ messages in thread
From: tip-bot for Qian Cai @ 2019-03-09 14:43 UTC (permalink / raw)
To: linux-tip-commits
Cc: dave.hansen, bp, linux-kernel, akpm, tglx, torvalds, bvanassche,
peterz, riel, luto, cai, mingo, hpa, will.deacon, paulmck
Commit-ID: 69a106c00e8554a7e6b3f4bb2967332670f89337
Gitweb: https://git.kernel.org/tip/69a106c00e8554a7e6b3f4bb2967332670f89337
Author: Qian Cai <cai@lca.pw>
AuthorDate: Wed, 6 Mar 2019 19:27:31 -0500
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Sat, 9 Mar 2019 14:15:52 +0100
workqueue, lockdep: Fix a memory leak in wq->lock_name
The following commit:
669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for workqueues")
introduced a memory leak as wq_free_lockdep() calls kfree(wq->lock_name),
but wq_init_lockdep() does not point wq->lock_name to the newly allocated
slab object.
This can be reproduced by running LTP fallocate04 followed by oom01 tests:
unreferenced object 0xc0000005876384d8 (size 64):
comm "fallocate04", pid 26972, jiffies 4297139141 (age 40370.480s)
hex dump (first 32 bytes):
28 77 71 5f 63 6f 6d 70 6c 65 74 69 6f 6e 29 65 (wq_completion)e
78 74 34 2d 72 73 76 2d 63 6f 6e 76 65 72 73 69 xt4-rsv-conversi
backtrace:
[<00000000cb452883>] kvasprintf+0x6c/0xe0
[<000000004654ddac>] kasprintf+0x34/0x60
[<000000001c68f311>] alloc_workqueue+0x1f8/0x6ac
[<0000000003c2ad83>] ext4_fill_super+0x23d4/0x3c80 [ext4]
[<0000000006610538>] mount_bdev+0x25c/0x290
[<00000000bcf955ec>] ext4_mount+0x28/0x50 [ext4]
[<0000000016e08fd3>] legacy_get_tree+0x4c/0xb0
[<0000000042b6a5fc>] vfs_get_tree+0x6c/0x190
[<00000000268ab022>] do_mount+0xb9c/0x1100
[<00000000698e6898>] ksys_mount+0x158/0x180
[<0000000064e391fd>] sys_mount+0x20/0x30
[<00000000ba378f12>] system_call+0x5c/0x70
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: catalin.marinas@arm.com
Cc: jiangshanlai@gmail.com
Cc: tj@kernel.org
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for workqueues")
Link: https://lkml.kernel.org/r/20190307002731.47371-1-cai@lca.pw
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
kernel/workqueue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index ecdd5e6f2166..e14da4f599ab 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3348,6 +3348,8 @@ static void wq_init_lockdep(struct workqueue_struct *wq)
lock_name = kasprintf(GFP_KERNEL, "%s%s", "(wq_completion)", wq->name);
if (!lock_name)
lock_name = wq->name;
+
+ wq->lock_name = lock_name;
lockdep_init_map(&wq->lockdep_map, lock_name, &wq->key, 0);
}
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-03-09 14:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-07 0:27 [PATCH] workqueue: fix a memory leak in wq->lock_name Qian Cai
2019-03-09 14:43 ` [tip:locking/urgent] workqueue, lockdep: Fix " tip-bot for Qian Cai
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).