From: Yunseong Kim <ysk@kzalloc.com>
To: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Austin Kim <austindh.kim@gmail.com>,
linux-rt-devel@lists.linux.dev, syzkaller@googlegroups.com,
stable@vger.kernel.org
Subject: Re: [BUG] arm64: Sleeping function called from invalid context in do_debug_exception on PREEMPT_RT
Date: Wed, 13 Aug 2025 16:42:24 +0900 [thread overview]
Message-ID: <17f91b9a-0a3a-47e1-bdfb-06237ae5da55@kzalloc.com> (raw)
In-Reply-To: <aJw3L7B7u5qAPOMz@e129823.arm.com>
Hi Yeoreum,
Thank you for pointing it!
On 8/13/25 3:56 PM, Yeoreum Yun wrote:
> Hi Yunseong,
>
>>
>> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
>> | in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20466, name: syz.0.1689
>> | preempt_count: 1, expected: 0
>> | RCU nest depth: 0, expected: 0
>> | Preemption disabled at:
>> | [<ffff800080241600>] debug_exception_enter arch/arm64/mm/fault.c:978 [inline]
>> | [<ffff800080241600>] do_debug_exception+0x68/0x2fc arch/arm64/mm/fault.c:997
>> | CPU: 0 UID: 0 PID: 20466 Comm: syz.0.1689 Not tainted 6.16.0-rc1-rt1-dirty #12 PREEMPT_RT
>> | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8 05/13/2025
>> | Call trace:
>> | show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)
>> | __dump_stack+0x30/0x40 lib/dump_stack.c:94
>> | dump_stack_lvl+0x148/0x1d8 lib/dump_stack.c:120
>> | dump_stack+0x1c/0x3c lib/dump_stack.c:129
>> | __might_resched+0x2e4/0x52c kernel/sched/core.c:8800
>> | __rt_spin_lock kernel/locking/spinlock_rt.c:48 [inline]
>> | rt_spin_lock+0xa8/0x1bc kernel/locking/spinlock_rt.c:57
>> | spin_lock include/linux/spinlock_rt.h:44 [inline]
>> | force_sig_info_to_task+0x6c/0x4a8 kernel/signal.c:1302
>> | force_sig_fault_to_task kernel/signal.c:1699 [inline]
>> | force_sig_fault+0xc4/0x110 kernel/signal.c:1704
>> | arm64_force_sig_fault+0x6c/0x80 arch/arm64/kernel/traps.c:265
>> | send_user_sigtrap arch/arm64/kernel/debug-monitors.c:237 [inline]
>> | single_step_handler+0x1f4/0x36c arch/arm64/kernel/debug-monitors.c:257
>> | do_debug_exception+0x154/0x2fc arch/arm64/mm/fault.c:1002
>> | el0_dbg+0x44/0x120 arch/arm64/kernel/entry-common.c:756
>> | el0t_64_sync_handler+0x3c/0x108 arch/arm64/kernel/entry-common.c:832
>> | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:600
>>
>>
>> It seems that commit eaff68b32861 ("arm64: entry: Add entry and exit functions
>> for debug exception") in 6.17-rc1, also present as 6fb44438a5e1 in mainline,
>> removed code that previously avoided sleeping context issues when handling
>> debug exceptions:
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/arch/arm64/mm/fault.c?id=eaff68b3286116d499a3d4e513a36d772faba587
>
> No. Her patch commit 31575e11ecf7 (arm64: debug: split brk64 exception entry)
> solves your splat since el0_brk64() doesn't call debug_exception_enter()
> by spliting el0/el1 brk64 entry exception entry.
>
> Formerly, el(0/1)_dbg() are handled in do_debug_exception() together
> and it calls debug_exception_enter() disabling preemption and this makes
> your splat while handling brk excepttion from el0.
>
Do you think a fix is necessary if this issue also affects the LTS kernel
before 6.17-rc1? As far as I know, most production RT kernels are still
based on the existing LTS versions.
>
> --
> Sincerely,
> Yeoreum Yun
Thank you,
Yunseong
next prev parent reply other threads:[~2025-08-13 7:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 5:01 [BUG] arm64: Sleeping function called from invalid context in do_debug_exception on PREEMPT_RT Yunseong Kim
2025-08-13 6:56 ` Yeoreum Yun
2025-08-13 7:42 ` Yunseong Kim [this message]
2025-08-13 8:59 ` Yeoreum Yun
2025-08-13 10:06 ` Luis Claudio R. Goncalves
2025-08-13 11:43 ` Ada Couprie Diaz
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=17f91b9a-0a3a-47e1-bdfb-06237ae5da55@kzalloc.com \
--to=ysk@kzalloc.com \
--cc=austindh.kim@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=paulmck@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzkaller@googlegroups.com \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.com \
/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