All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: rcu@vger.kernel.org, linux-rt-devel@lists.linux.dev,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Clark Williams <clrkwllms@kernel.org>
Subject: Re: [PATCH] rcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work
Date: Thu, 20 Aug 2026 15:55:00 +0200	[thread overview]
Message-ID: <20260820135500.hXUAsbHR@linutronix.de> (raw)
In-Reply-To: <aob12RahomSmpUQY@localhost.localdomain>

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

      reply	other threads:[~2026-08-20 13:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 11:00 [PATCH] rcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work Sebastian Andrzej Siewior
2026-08-20 12:40 ` Frederic Weisbecker
2026-08-20 13:55   ` Sebastian Andrzej Siewior [this message]

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=20260820135500.hXUAsbHR@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=clrkwllms@kernel.org \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.