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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250204102611.OVuHn9rS@linutronix.de>
Date: Tue, 4 Feb 2025 11:26:11 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org, Frederic Weisbecker <frederic@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alexei Starovoitov <ast@...nel.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH rcu v2] 4/5] rcu-tasks: Move RCU Tasks self-tests to
 core_initcall()

On 2025-01-30 10:53:19 [-0800], Paul E. McKenney wrote:
> The timer and hrtimer softirq processing has moved to dedicated threads
> for kernels built with CONFIG_IRQ_FORCED_THREADING=y.  This results in
> timers not expiring until later in early boot, which in turn causes the
> RCU Tasks self-tests to hang in kernels built with CONFIG_PROVE_RCU=y,
> which further causes the entire kernel to hang.  One fix would be to
> make timers work during this time, but there are no known users of RCU
> Tasks grace periods during that time, so no justification for the added
> complexity.  Not yet, anyway.
> 
> This commit therefore moves the call to rcu_init_tasks_generic() from
> kernel_init_freeable() to a core_initcall().  This works because the
> timer and hrtimer kthreads are created at early_initcall() time.

Fixes: 49a17639508c3 ("softirq: Use a dedicated thread for timer wakeups on PREEMPT_RT.")
?

I played with it and I can reproduce the issue with !RT + threadirqs but
not with RT (which implies threadirqs).
Is there anything in RT that avoids the problem?

Thank you for debugging and the patch. 

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ