netdev - Re: [PATCH] net: raise RCU qs after each threaded NAPI poll

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: <1880cb02-d259-46d8-b4f7-0b3e2e0f0745@paulmck-laptop>
Date: Wed, 28 Feb 2024 14:49:15 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Joel Fernandes <joel@...lfernandes.org>, Yan Zhai <yan@...udflare.com>,
	Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jiri Pirko <jiri@...nulli.us>, Simon Horman <horms@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Lorenzo Bianconi <lorenzo@...nel.org>,
	Coco Li <lixiaoyan@...gle.com>, Wei Wang <weiwan@...gle.com>,
	Alexander Duyck <alexanderduyck@...com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
	bpf@...r.kernel.org, kernel-team@...udflare.com,
	mark.rutland@....com,
	Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH] net: raise RCU qs after each threaded NAPI poll

On Wed, Feb 28, 2024 at 05:33:07PM -0500, Steven Rostedt wrote:
> On Wed, 28 Feb 2024 14:19:11 -0800
> "Paul E. McKenney" <paulmck@...nel.org> wrote:
> 
> > > > 
> > > > Well, to your initial point, cond_resched() does eventually invoke
> > > > preempt_schedule_common(), so you are quite correct that as far as
> > > > Tasks RCU is concerned, cond_resched() is not a quiescent state.  
> > > 
> > >  Thanks for confirming. :-)  
> > 
> > However, given that the current Tasks RCU use cases wait for trampolines
> > to be evacuated, Tasks RCU could make the choice that cond_resched()
> > be a quiescent state, for example, by adjusting rcu_all_qs() and
> > .rcu_urgent_qs accordingly.
> > 
> > But this seems less pressing given the chance that cond_resched() might
> > go away in favor of lazy preemption.
> 
> Although cond_resched() is technically a "preemption point" and not truly a
> voluntary schedule, I would be happy to state that it's not allowed to be
> called from trampolines, or their callbacks. Now the question is, does BPF
> programs ever call cond_resched()? I don't think they do.

Nor do I, but I too must defer to Alexei.  ;-)

> [ Added Alexei ]

The other issue with making cond_resched() be a Tasks RCU quiescent
state is that the CONFIG_PREEMPTION=y version of cond_resched() would
need to stop being a complete no-op.  Which actually might be OK.

							Thanx, Paul