All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linuxppc-dev@lists.ozlabs.org
Subject: [Bug 216156] [bisected] kmemleak: Not scanning unknown object at 0xc00000007f000000
Date: Thu, 05 Oct 2023 23:41:03 +0000	[thread overview]
Message-ID: <bug-216156-206035-9mQgxTI3Kz@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-216156-206035@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=216156

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

  parent reply	other threads:[~2023-10-05 23:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20 23:14 [Bug 216156] New: kmemleak: Not scanning unknown object at 0xc00000007f000000 bugzilla-daemon
2022-06-20 23:15 ` [Bug 216156] " bugzilla-daemon
2022-06-20 23:30 ` bugzilla-daemon
2022-06-20 23:37 ` bugzilla-daemon
2022-08-25  0:39 ` bugzilla-daemon
2022-08-25  0:40 ` bugzilla-daemon
2022-11-14 22:11 ` bugzilla-daemon
2022-11-14 22:12 ` bugzilla-daemon
2023-08-19 23:00 ` bugzilla-daemon
2023-08-19 23:01 ` bugzilla-daemon
2023-10-05 23:41 ` bugzilla-daemon [this message]
2023-10-05 23:43 ` [Bug 216156] [bisected] " bugzilla-daemon
2023-10-05 23:43 ` bugzilla-daemon
2023-10-09  4:36 ` bugzilla-daemon
2023-10-09 15:50 ` bugzilla-daemon
2023-10-10 12:14 ` bugzilla-daemon
2023-10-10 18:21 ` bugzilla-daemon
2024-04-19  8:30 ` bugzilla-daemon

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=bug-216156-206035-9mQgxTI3Kz@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.