linux-kernel - Re: [PATCH 1/5] torture: Remove support for SRCU-lite

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: <167ab1f0-ea85-4a0f-8a19-1d74e2fa7439@paulmck-laptop>
Date: Thu, 26 Jun 2025 03:54:06 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org
Subject: Re: [PATCH 1/5] torture: Remove support for SRCU-lite

On Wed, Jun 25, 2025 at 05:05:47AM -0700, Christoph Hellwig wrote:
> On Tue, Jun 24, 2025 at 09:13:56AM -0700, Paul E. McKenney wrote:
> > Because SRCU-lite is being replaced by SRCU-fast, this commit removes
> > support for SRCU-lite from refscale.c.
> 
> Please explain how they different and why one is a good enough (or
> even better?) replacement for the other.

Ah, good point, thank you!

How about if I add this to the cover letter?

	Both SRCU-lite and SRCU-fast provide faster readers by dropping
	the smp_mb() call from their lock and unlock primitives.
	The price of this is a pair of added RCU grace periods during
	the SRCU grace period.

	SRCU-fast also adds NMI safety for architectures that have
	NMIs but do not have NMI-safe per-CPU operations.  In addition,
	srcu_read_lock_fast() returns a per-CPU pointer rather than an
	integer, which provides a further speedup compared to SRCU-lite
	by getting rid of array-index calculations.

	There is a trivial mapping from the SRCU-lite API to that
	of SRCU-fast, so we do not expect any transition issues.
	In addition, while SRCU-lite remains in the kernel, checkpatch.pl
	will warn about added SRCU-lite use cases.

	Further read-side speedups are possible, but they amount to only
	about half a nanosecond out of about two nanoseconds (measured on
	my x86 laptop), and they might require some changes to existing
	SRCU code.  These changes are trivial, but we need to see a
	solid need for the additional performance before inconveniencing
	existing users.

							Thanx, Paul