mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Zqiang <qiang.zhang@linux.dev>
Cc: frederic@kernel.org, neeraj.upadhyay@kernel.org,
	joelagnelf@nvidia.com, urezki@gmail.com, boqun@kernel.org,
	rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu-tasks: Remove smp_mb() in rcu_spawn_tasks_kthread_generic()
Date: Fri, 10 Jul 2026 11:25:01 -0700	[thread overview]
Message-ID: <8e1b325f-f26a-4c2b-b36f-c13a0335d95a@paulmck-laptop> (raw)
In-Reply-To: <20260710115028.30303-1-qiang.zhang@linux.dev>

On Fri, Jul 10, 2026 at 07:50:28PM +0800, Zqiang wrote:
> The smp_mb() after kthread_run() in rcu_spawn_tasks_kthread_generic()
> from early 'commit eacd6f04a133 ("rcu-tasks: Move Tasks RCU to its
> own file")' and 'commit 84a8f446ffd7 ("rcu: Defer rcu_tasks_kthread()
> creation till first call_rcu_tasks()")', the pairing as follows:
> 
> rcu_spawn_tasks_kthread()
> ->t = kthread_run(rcu_tasks_kthread, ...);
> ->smp_mb(); /* Ensure others see full kthread. */
> ->WRITE_ONCE(rcu_tasks_kthread_ptr, t);
> 
> 							call_rcu_tasks()
> 					      		->if (READ_ONCE(rcu_tasks_kthread_ptr))
> 					         	  ->wake_up(&rcu_tasks_cbs_wq)
> 							    ->try_to_wake_up()
> 							      lock pi_lock
> 							      ->smp_mb__after_spinlock()
> 								//see full kthread
> 
> Currently, the 'commit d119357d0743 ("rcu-tasks: Treat only synchronous
> grace periods urgently")' moved kthread_ptr assignment into the
> rcu_tasks_kthread(), the following pairings are sufficient:
> 
> The rq->lock/unlock from wake_up_process() in kthread_run() and
> __schedule() provides a memory barrier when the kthread is first
> scheduled, this ensures the kthread itself observes all of the
> kthread's initialization.
> 
> The kthread's smp_store_release(&rtp->kthread_ptr, ...) in
> rcu_tasks_kthread() and smp_load_acquire(&rtp->kthread_ptr) in
> call_rcu_tasks_generic() compose release/acquire pairing, the
> cumulativity of smp_store_release() propagates visibility of the
> kthread's initialization through the scheduler chain.
> 
> This commit therefore remove smp_mb() in rcu_spawn_tasks_kthread_generic().
> 
> Signed-off-by: Zqiang <qiang.zhang@linux.dev>

Very good, a removal of an smp_mb() that also simplifies analysis!

One question...

> ---
>  kernel/rcu/tasks.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> index 5a8db89135eb..18ab335665e3 100644
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -395,7 +395,6 @@ static void call_rcu_tasks_generic(struct rcu_head *rhp, rcu_callback_t func,
>  		raw_spin_unlock_irqrestore(&rtp->cbs_gbl_lock, flags);
>  	}
>  	rcu_read_unlock();
> -	/* We can't create the thread unless interrupts are enabled. */

Why remove this comment?  People reading this code might wonder why we
are not just invoking rcu_spawn_tasks_kthread_generic() to create the
task here.

Now, if you say that the current comment is confusing because if that
kthread already exists, we also defer the wakeup, fair enough.  But in
that case, could you please propose a replacement comment, perhaps as
a separate patch?

							Thanx, Paul

>  	if (needwake && READ_ONCE(rtp->kthread_ptr))
>  		irq_work_queue(&rtpcp->rtp_irq_work);
>  }
> @@ -681,7 +680,6 @@ static void __init rcu_spawn_tasks_kthread_generic(struct rcu_tasks *rtp)
>  	t = kthread_run(rcu_tasks_kthread, rtp, "%s_kthread", rtp->kname);
>  	if (WARN_ONCE(IS_ERR(t), "%s: Could not start %s grace-period kthread, OOM is now expected behavior\n", __func__, rtp->name))
>  		return;
> -	smp_mb(); /* Ensure others see full kthread. */
>  }
>  
>  #ifndef CONFIG_TINY_RCU
> -- 
> 2.17.1
> 

  reply	other threads:[~2026-07-10 18:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 11:50 Zqiang
2026-07-10 18:25 ` Paul E. McKenney [this message]
2026-07-10 23:18   ` Zqiang
2026-07-11  2:48     ` Paul E. McKenney
2026-07-11  5:09       ` Zqiang
2026-07-11 23:56         ` Paul E. McKenney

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=8e1b325f-f26a-4c2b-b36f-c13a0335d95a@paulmck-laptop \
    --to=paulmck@kernel.org \
    --cc=boqun@kernel.org \
    --cc=frederic@kernel.org \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=qiang.zhang@linux.dev \
    --cc=rcu@vger.kernel.org \
    --cc=urezki@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox