linux-kernel - Re: [PATCH v2 6/6] rcu-tasks: Maintain real-time response in rcu_tasks

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: <ZdeI_-RfdLR8jlsm@localhost.localdomain>
Date: Thu, 22 Feb 2024 18:48:47 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
	Neeraj Upadhyay <Neeraj.Upadhyay@....com>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sebastian Siewior <bigeasy@...utronix.de>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Neeraj Upadhyay <quic_neeraju@...cinc.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Josh Triplett <josh@...htriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang1211@...il.com>
Subject: Re: [PATCH v2 6/6] rcu-tasks: Maintain real-time response in
 rcu_tasks_postscan()

Le Fri, Feb 16, 2024 at 05:27:41PM -0800, Boqun Feng a écrit :
> From: "Paul E. McKenney" <paulmck@...nel.org>
> 
> The current code will scan the entirety of each per-CPU list of exiting
> tasks in ->rtp_exit_list with interrupts disabled.  This is normally just
> fine, because each CPU typically won't have very many tasks in this state.
> However, if a large number of tasks block late in do_exit(), these lists
> could be arbitrarily long.  Low probability, perhaps, but it really
> could happen.
> 
> This commit therefore occasionally re-enables interrupts while traversing
> these lists, inserting a dummy element to hold the current place in the
> list.  In kernels built with CONFIG_PREEMPT_RT=y, this re-enabling happens
> after each list element is processed, otherwise every one-to-two jiffies.
> 
> Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Sebastian Siewior <bigeasy@...utronix.de>
> Cc: Anna-Maria Behnsen <anna-maria@...utronix.de>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> ---
>  kernel/rcu/tasks.h | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> index 4dc355b2ac22..866743e0796f 100644
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -971,13 +971,32 @@ static void rcu_tasks_postscan(struct list_head *hop)
>  	 */
>  
>  	for_each_possible_cpu(cpu) {
> +		unsigned long j = jiffies + 1;
>  		struct rcu_tasks_percpu *rtpcp = per_cpu_ptr(rcu_tasks.rtpcpu, cpu);
>  		struct task_struct *t;
> +		struct task_struct *t1;
> +		struct list_head tmp;
>  
>  		raw_spin_lock_irq_rcu_node(rtpcp);
> -		list_for_each_entry(t, &rtpcp->rtp_exit_list, rcu_tasks_exit_list)
> +		list_for_each_entry_safe(t, t1, &rtpcp->rtp_exit_list, rcu_tasks_exit_list) {
>  			if (list_empty(&t->rcu_tasks_holdout_list))
>  				rcu_tasks_pertask(t, hop);
> +
> +			// RT kernels need frequent pauses, otherwise
> +			// pause at least once per pair of jiffies.
> +			if (!IS_ENABLED(CONFIG_PREEMPT_RT) && time_before(jiffies, j))
> +				continue;
> +
> +			// Keep our place in the list while pausing.
> +			// Nothing else traverses this list, so adding a
> +			// bare list_head is OK.
> +			list_add(&tmp, &t->rcu_tasks_exit_list);

I'm a bit confused about what this does...

> +			raw_spin_unlock_irq_rcu_node(rtpcp);
> +			cond_resched(); // For CONFIG_PREEMPT=n kernels
> +			raw_spin_lock_irq_rcu_node(rtpcp);
> +			list_del(&tmp);

Isn't there a risk that t is reaped by then? If it was not observed on_rq
while calling rcu_tasks_pertask() then there is no get_task_struct.

And what about t1? Can't it be reaped as well?

Thanks.


> +			j = jiffies + 1;
> +		}
>  		raw_spin_unlock_irq_rcu_node(rtpcp);
>  	}
>  
> -- 
> 2.43.0
>