[Bug 216156] [bisected] kmemleak: Not scanning unknown object at 0xc00000007f000000

bugzilla-daemon at kernel.org bugzilla-daemon at kernel.org
Fri Oct 6 10:41:03 AEDT 2023


Erhard F. (erhard_f at 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. (erhard_f at 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.shcn at 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
      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:

    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.

    Signed-off-by: Patrick Wang <patrick.wang.shcn at gmail.com>
    Acked-by: Catalin Marinas <catalin.marinas at arm.com>
    Cc: <stable at vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds at 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.

More information about the Linuxppc-dev mailing list