https://bugzilla.kernel.org/show_bug.cgi?id=216156
Erhard F. (erhar...@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|kmemleak: Not scanning |[bisected] kmemleak: Not
|unknown object at |scanning unknown object at
|0xc00000007f000000 |0xc00000007f000000
--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
Finally had some time to bisect this issue.
# git bisect bad
23c2d497de21f25898fbea70aeb292ab8acc8c94 is the first bad commit
commit 23c2d497de21f25898fbea70aeb292ab8acc8c94
Author: Patrick Wang <patrick.wang.s...@gmail.com>
Date: Thu Apr 14 19:14:04 2022 -0700
mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
The kmemleak_*_phys() apis do not check the address for lowmem's min
boundary, while the caller may pass an address below lowmem, which will
trigger an oops:
# echo scan > /sys/kernel/debug/kmemleak
Unable to handle kernel paging request at virtual address
ff5fffffffe00000
Oops [#1]
Modules linked in:
CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33
Hardware name: riscv-virtio,qemu (DT)
epc : scan_block+0x74/0x15c
ra : scan_block+0x72/0x15c
epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30
gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200
t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90
s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000
a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001
a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005
s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90
s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0
s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000
s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f
t5 : 0000000000000001 t6 : 0000000000000000
status: 0000000000000100 badaddr: ff5fffffffe00000 cause:
000000000000000d
scan_gray_list+0x12e/0x1a6
kmemleak_scan+0x2aa/0x57e
kmemleak_write+0x32a/0x40c
full_proxy_write+0x56/0x82
vfs_write+0xa6/0x2a6
ksys_write+0x6c/0xe2
sys_write+0x22/0x2a
ret_from_syscall+0x0/0x2
The callers may not quite know the actual address they pass(e.g. from
devicetree). So the kmemleak_*_phys() apis should guarantee the address
they finally use is in lowmem range, so check the address for lowmem's
min boundary.
Link:
https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.s...@gmail.com
Signed-off-by: Patrick Wang <patrick.wang.s...@gmail.com>
Acked-by: Catalin Marinas <catalin.mari...@arm.com>
Cc: <sta...@vger.kernel.org>
Signed-off-by: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
mm/kmemleak.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
And indeed if I revert 23c2d497de21f25898fbea70aeb292ab8acc8c94 (on top of 5.19
as mm/kmemleak.c differs too much in later kernels) the "kmemleak: Not scanning
unknown object at 0xc00000007f000000" is gone.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
