linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "WangzXD0325@outlook.com" <WangzXD0325@outlook.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: "rcu@vger.kernel.org" <rcu@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [BUG] rcu_preempt self-detected stall during kmemleak_scan via debugfs write (6.18.0)
Date: Wed, 7 Jan 2026 05:12:53 +0000	[thread overview]
Message-ID: <KL1PR03MB8800B64AFA0A40CFF301C50CA184A@KL1PR03MB8800.apcprd03.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

Hello,
I am reporting a possible RCU stall observed during fuzz testing on a
recent kernel.
=== Summary ===
The kernel reports an "rcu_preempt self-detected stall" while executing
kmemleak scanning code, apparently triggered via a debugfs write. The
stall happens inside a spin_unlock_irqrestore() path during kmemleak
object scanning.
This was observed under syzkaller-style fuzzing (syz-executor). I do not
currently have a minimal reproducer.
=== Environment ===
Kernel: 6.18.0 (locally built)
Config: PREEMPT(voluntary)
Arch: x86_64
Hardware: QEMU Standard PC (i440FX + PIIX)
CPU count: 4
Workload: syz-executor (fuzzing)
=== Observed behavior ===
Kernel reports an RCU stall:
INFO: rcu detected stall in corrupted
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 2-...!: (63 ticks this GP)
rcu: (t=263136 jiffies g=235149 q=10 ncpus=4)
The stall occurs on CPU 2 while running syz-executor.
=== Call trace (relevant part) ===
The stack trace points into kmemleak scanning code invoked via debugfs:
scan_object mm/kmemleak.c:1615
scan_gray_list mm/kmemleak.c:1648
kmemleak_scan mm/kmemleak.c:1800
kmemleak_write mm/kmemleak.c:2172
full_proxy_write fs/debugfs/file.c:388
vfs_write
ksys_write
do_syscall_64
The instruction pointer at the time of the stall is in:
_raw_spin_unlock_irqrestore
kernel/locking/spinlock.c:194
=== Additional observations ===
The system later shows journal corruption and systemd-journald being
restarted by the watchdog, possibly as a secondary effect.
syzkaller reports:
SYZFAIL: failed to recv rpc (errno 9: Bad file descriptor)
It is unclear whether this is directly related to the RCU stall or a
consequence of the system becoming unresponsive.
=== Reproducer ===
No standalone reproducer is currently available.
The issue was observed during fuzzing with syz-executor.
=== Expected behavior ===
No RCU stall should be reported during kmemleak scanning, even under
malformed or adversarial debugfs inputs.
=== Actual behavior ===
RCU reports a self-detected stall while executing kmemleak_scan.
=== Notes ===
This may indicate that kmemleak scanning holds preemption or interrupts
disabled for longer than expected under certain conditions, or that an
RCU read-side critical section is not being exited promptly.
Please let me know if additional information, kernel config details, or
further testing would be helpful.
Thanks for your time.
Reported-by:
Zhi Wang


[-- Attachment #2: Type: text/html, Size: 3976 bytes --]

                 reply	other threads:[~2026-01-07  5:13 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=KL1PR03MB8800B64AFA0A40CFF301C50CA184A@KL1PR03MB8800.apcprd03.prod.outlook.com \
    --to=wangzxd0325@outlook.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.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