[PATCH] rcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work

[PATCH] rcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work

[Sebastian Andrzej Siewior]

The irq_work in srcu is used to schedule a delayed work. The work item
is not scheduled directly because it is not always possible wake a
thread directly.

On PREEMPT_RT the default irq_work is initialized with IRQ_WORK_LAZY and
is delayed to the irq_work thread. A system booted with the command line
"trace_event=…" will freeze during boot because the irq_work thread is
not yet deployed (and tracing uses synchronize_srcu() in
tp_rcu_cond_sync()).

The irq_work performs just a wakeup a thread, there is nothing wrong
with doing this from hardirq context on PREEMPT_RT.

Use IRQ_WORK_INIT_HARD for srcu's irq_work.

Fixes: 7c405fb3279b3 ("rcu: Use an intermediate irq_work to start process_srcu()")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 kernel/rcu/srcutree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 7c2f7cc131f7a..b703233d4a63f 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -218,7 +218,7 @@ static int init_srcu_struct_fields(struct srcu_struct *ssp, bool is_static)
 	mutex_init(&ssp->srcu_sup->srcu_barrier_mutex);
 	atomic_set(&ssp->srcu_sup->srcu_barrier_cpu_cnt, 0);
 	INIT_DELAYED_WORK(&ssp->srcu_sup->work, process_srcu);
-	init_irq_work(&ssp->srcu_sup->irq_work, srcu_irq_work);
+	ssp->srcu_sup->irq_work = IRQ_WORK_INIT_HARD(srcu_irq_work);
 	ssp->srcu_sup->sda_is_static = is_static;
 	if (!is_static) {
 		ssp->sda = alloc_percpu(struct srcu_data);
-- 
2.55.0

Re: [PATCH] rcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work

[Frederic Weisbecker]

Le Thu, Aug 20, 2026 at 01:00:08PM +0200, Sebastian Andrzej Siewior a écrit :
> The irq_work in srcu is used to schedule a delayed work. The work item
> is not scheduled directly because it is not always possible wake a
> thread directly.
> 
> On PREEMPT_RT the default irq_work is initialized with IRQ_WORK_LAZY and
> is delayed to the irq_work thread. A system booted with the command line
> "trace_event=…" will freeze during boot because the irq_work thread is
> not yet deployed (and tracing uses synchronize_srcu() in
> tp_rcu_cond_sync()).
> 
> The irq_work performs just a wakeup a thread, there is nothing wrong
> with doing this from hardirq context on PREEMPT_RT.
> 
> Use IRQ_WORK_INIT_HARD for srcu's irq_work.
> 
> Fixes: 7c405fb3279b3 ("rcu: Use an intermediate irq_work to start process_srcu()")
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  kernel/rcu/srcutree.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 7c2f7cc131f7a..b703233d4a63f 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -218,7 +218,7 @@ static int init_srcu_struct_fields(struct srcu_struct *ssp, bool is_static)
>  	mutex_init(&ssp->srcu_sup->srcu_barrier_mutex);
>  	atomic_set(&ssp->srcu_sup->srcu_barrier_cpu_cnt, 0);
>  	INIT_DELAYED_WORK(&ssp->srcu_sup->work, process_srcu);
> -	init_irq_work(&ssp->srcu_sup->irq_work, srcu_irq_work);
> +	ssp->srcu_sup->irq_work = IRQ_WORK_INIT_HARD(srcu_irq_work);

It may need a comment to not lose that.

>  	ssp->srcu_sup->sda_is_static = is_static;
>  	if (!is_static) {
>  		ssp->sda = alloc_percpu(struct srcu_data);
> -- 
> 2.55.0
> 
>

Perhaps all irq works queued before the relevant kthread is started should
temporarily be queued as hard?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs

Re: [PATCH] rcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work

[Sebastian Andrzej Siewior]

On 2026-08-20 14:40:57 [+0200], Frederic Weisbecker wrote:
> Le Thu, Aug 20, 2026 at 01:00:08PM +0200, Sebastian Andrzej Siewior a écrit :
> > The irq_work in srcu is used to schedule a delayed work. The work item
> > is not scheduled directly because it is not always possible wake a
> > thread directly.
> > 
> > On PREEMPT_RT the default irq_work is initialized with IRQ_WORK_LAZY and
> > is delayed to the irq_work thread. A system booted with the command line
> > "trace_event=…" will freeze during boot because the irq_work thread is
> > not yet deployed (and tracing uses synchronize_srcu() in
> > tp_rcu_cond_sync()).
> > 
> > The irq_work performs just a wakeup a thread, there is nothing wrong
> > with doing this from hardirq context on PREEMPT_RT.
> > 
> > Use IRQ_WORK_INIT_HARD for srcu's irq_work.
> > 
> > Fixes: 7c405fb3279b3 ("rcu: Use an intermediate irq_work to start process_srcu()")
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  kernel/rcu/srcutree.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index 7c2f7cc131f7a..b703233d4a63f 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -218,7 +218,7 @@ static int init_srcu_struct_fields(struct srcu_struct *ssp, bool is_static)
> >  	mutex_init(&ssp->srcu_sup->srcu_barrier_mutex);
> >  	atomic_set(&ssp->srcu_sup->srcu_barrier_cpu_cnt, 0);
> >  	INIT_DELAYED_WORK(&ssp->srcu_sup->work, process_srcu);
> > -	init_irq_work(&ssp->srcu_sup->irq_work, srcu_irq_work);
> > +	ssp->srcu_sup->irq_work = IRQ_WORK_INIT_HARD(srcu_irq_work);
> 
> It may need a comment to not lose that.

We could also make irq_work.o earlier in the Makefile, right at the top
so it comes before tracing. This was one of the first ideas and makes
the issue also go away. But given that it is just a wake we avoid waking
the irq_work/ thread just to schedule a timer/ wake workqueue.

> >  	ssp->srcu_sup->sda_is_static = is_static;
> >  	if (!is_static) {
> >  		ssp->sda = alloc_percpu(struct srcu_data);
> > -- 
> > 2.55.0
> > 
> >
> 
> Perhaps all irq works queued before the relevant kthread is started should
> temporarily be queued as hard?

Urgh. irq_work shouldn't become a widespread user ;)
If the scheduler is up but irq_work thread is not yet created and the
irq_work uses sleeping locks then it would create warnings.
In testing right now I see just wake_up_klogd_work_func() which is
always LAZY but would qualify otherwise for a warning. We wouldn't
trigger anything yet but you get the idea.

> Thanks.

Sebastian