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

Sebastian Andrzej Siewior <[email protected]>
Newsgroups dev.linux.lists.linux-rt-devel,org.kernel.vger.rcu
Message-ID <[email protected]>
On 2026-08-21 12:04:31 [+0200], To Steven Rostedt wrote:
> On 2026-08-20 13:00:28 [-0400], Steven Rostedt wrote:
> > On Thu, 20 Aug 2026 15:55:00 +0200
> > Sebastian Andrzej Siewior <[email protected]> wrote:
> > 
> > > > > 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.  
> > 
> > I agree a comment would be useful here.
> Urgh.

What do you want me to cover in the comment? The arguing pro
IRQ_WORK_INIT_HARD is because it is "just" a workqueue schedule and it
avoids the jump over irq_work/ thread. This makes sense regardless of
the tracing issue.
If it would be not compatible with hard-irq context I would argue for
the makefile change which is still sane since there is no other way to
express dependencies (which we clearly have here).

Sebastian
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.