linux-kernel - Re: [PATCH stable] notifiers: Add oops check in blocking_notifier_call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20251017152542.33202c28377ec9b86713ff4a@linux-foundation.org>
Date: Fri, 17 Oct 2025 15:25:42 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Yi Yang <yiyang13@...wei.com>
Cc: Alexey Dobriyan <adobriyan@...ru>, <linux-kernel@...r.kernel.org>,
 <stable@...r.kernel.org>, <lujialin4@...wei.com>, Simona Vetter
 <simona@...ll.ch>
Subject: Re: [PATCH stable] notifiers: Add oops check in
 blocking_notifier_call_chain()

On Fri, 17 Oct 2025 06:17:40 +0000 Yi Yang <yiyang13@...wei.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;
> +			}
> +		}
>  	}
>  	return ret;

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.