linux-kernel - Re: [PATCH v2 19/28] LoongArch: ftrace: Use RCU in all users of __module_text

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] [day] [month] [year] [list]

Message-ID: <20250107171247.gzibqLkQ@linutronix.de>
Date: Tue, 7 Jan 2025 18:12:47 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Gomez <da.gomez@...sung.com>,
	Luis Chamberlain <mcgrof@...nel.org>,
	"Paul E . McKenney" <paulmck@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Petr Pavlu <petr.pavlu@...e.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Huacai Chen <chenhuacai@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	WANG Xuerui <kernel@...0n.name>, linux-trace-kernel@...r.kernel.org,
	loongarch@...ts.linux.dev
Subject: Re: [PATCH v2 19/28] LoongArch: ftrace: Use RCU in all users of
 __module_text_address().

On 2024-12-27 12:19:46 [-0500], Steven Rostedt wrote:
…
> Is easier to understand than:
> 
> 	if (!mod) {
> 		guard(rcu)();
> 		mod = __module_text_address(pc);
> 	}
> 
> Because it makes me wonder, why use a guard() for a one liner?

Why not? The context ends immediately after.

> But, when I saw your other patch, if we had:
> 
> 	if (!mod) {
> 		scoped_guard(rcu)()
> 			mod = __module_text_address(pc);
> 	}

Okay, if this looks better, let me update it. It just you already have a
scope (the {} after the if) and then we start yet another block. But if
this looks better so be it.

> To me, hat looks much better than the guard() as it is obvious to what the
> code is protecting. Even though, I still prefer the explicit, lock/unlock.
> Maybe, just because I'm more used to it.

I'm probably also used to the explicit part but numerous people said to
use this from now on. And it results in less lines and you don't have to
worry about each return statement. So it somehow looks/ feels line an
upgrade.

> IMHO, guard() is for complex functions that are error prone. A single line
> is not something that is error prone (unless you don't match the lock and
> unlock properly, but that's pretty obvious when that happens).

True but this is now a one liner which might be extended later on. Also
the context is one line.

> But this is just my own opinion.
> 
> -- Steve

Sebastian