On Fri, 17 Oct 2025 06:17:40 +0000 Yi Yang yiyang13@huawei.com wrote:
In hrtimer_interrupt(), interrupts are disabled when acquiring a spinlock, which subsequently triggers an oops. During the oops call chain, blocking_notifier_call_chain() invokes _cond_resched, ultimately leading to a hard lockup.
Call Stack: hrtimer_interrupt//raw_spin_lock_irqsave __hrtimer_run_queues page_fault do_page_fault bad_area_nosemaphore no_context oops_end bust_spinlocks unblank_screen do_unblank_screen fbcon_blank fb_notifier_call_chain blocking_notifier_call_chain down_read _cond_resched
Seems this trace is upside-down relative to what we usually see.
Is the unaltered dmesg output available?
If the system is in an oops state, use down_read_trylock instead of a blocking lock acquisition. If the trylock fails, skip executing the notifier callbacks to avoid potential deadlocks or unsafe operations during the oops handling process.
...
--- a/kernel/notifier.c +++ b/kernel/notifier.c @@ -384,9 +384,18 @@ int blocking_notifier_call_chain(struct blocking_notifier_head *nh, * is, we re-check the list after having taken the lock anyway: */ if (rcu_access_pointer(nh->head)) {
down_read(&nh->rwsem);ret = notifier_call_chain(&nh->head, val, v, -1, NULL);up_read(&nh->rwsem);
if (!oops_in_progress) {down_read(&nh->rwsem);ret = notifier_call_chain(&nh->head, val, v, -1, NULL);up_read(&nh->rwsem);} else {if (down_read_trylock(&nh->rwsem)) {ret = notifier_call_chain(&nh->head, val, v, -1, NULL);up_read(&nh->rwsem);} else {ret = NOTIFY_BAD;}}
Am I correct in believing that fb_notifier_call_chain() is only ever called if defined(CONFIG_GUMSTIX_AM200EPD)?
I wonder what that call is for, and if we can simply remove it.