From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
Daniel Gomez <da.gomez@samsung.com>,
Luis Chamberlain <mcgrof@kernel.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Petr Pavlu <petr.pavlu@suse.com>,
Sami Tolvanen <samitolvanen@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Huacai Chen <chenhuacai@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
linux-trace-kernel@vger.kernel.org, loongarch@lists.linux.dev
Subject: Re: [PATCH v2 19/28] LoongArch: ftrace: Use RCU in all users of __module_text_address().
Date: Tue, 7 Jan 2025 18:12:47 +0100 [thread overview]
Message-ID: <20250107171247.gzibqLkQ@linutronix.de> (raw)
In-Reply-To: <20241227121946.1643decf@gandalf.local.home>
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
next prev parent reply other threads:[~2025-01-07 17:12 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 17:41 [PATCH v2 00/28] module: Use RCU instead of RCU-sched Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 01/28] module: Extend the preempt disabled section in dereference_symbol_descriptor() Sebastian Andrzej Siewior
2025-01-07 10:58 ` Sergey Senozhatsky
2024-12-20 17:41 ` [PATCH v2 02/28] module: Begin to move from RCU-sched to RCU Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 03/28] module: Use proper RCU assignment in add_kallsyms() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 04/28] module: Use RCU in find_kallsyms_symbol() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 05/28] module: Use RCU in module_get_kallsym() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 06/28] module: Use RCU in find_module_all() Sebastian Andrzej Siewior
2025-01-02 14:16 ` Petr Mladek
2024-12-20 17:41 ` [PATCH v2 07/28] module: Use RCU in __find_kallsyms_symbol_value() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 08/28] module: Use RCU in module_kallsyms_on_each_symbol() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 09/28] module: Remove module_assert_mutex_or_preempt() from try_add_tainted_module() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 10/28] module: Use RCU in find_symbol() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 11/28] module: Use RCU in __is_module_percpu_address() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 12/28] module: Allow __module_address() to be called from RCU section Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 13/28] module: Use RCU in search_module_extables() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 14/28] module: Use RCU in all users of __module_address() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 15/28] module: Use RCU in all users of __module_text_address() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 16/28] ARM: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 17/28] arm64: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 18/28] LoongArch/orc: Use RCU in all users of __module_address() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 19/28] LoongArch: ftrace: Use RCU in all users of __module_text_address() Sebastian Andrzej Siewior
2024-12-27 17:19 ` Steven Rostedt
2025-01-07 17:12 ` Sebastian Andrzej Siewior [this message]
2024-12-20 17:41 ` [PATCH v2 20/28] powerpc/ftrace: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 21/28] x86: Use RCU in all users of __module_address() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 22/28] jump_label: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 23/28] jump_label: Use RCU in all users of __module_text_address() Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 24/28] bpf: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 25/28] kprobes: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 26/28] static_call: " Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 27/28] bug: Use RCU instead RCU-sched to protect module_bug_list Sebastian Andrzej Siewior
2024-12-20 17:41 ` [PATCH v2 28/28] cfi: Use RCU while invoking __module_address() Sebastian Andrzej Siewior
2024-12-30 21:13 ` Petr Pavlu
2025-01-02 23:59 ` Sami Tolvanen
2024-12-31 3:33 ` Elliot Berman
2025-01-03 0:24 ` Sami Tolvanen
2025-01-06 18:00 ` Elliot Berman
2025-01-06 21:24 ` Sami Tolvanen
2025-01-07 15:44 ` Sebastian Andrzej Siewior
2025-01-02 12:47 ` [PATCH v2 00/28] module: Use RCU instead of RCU-sched Christophe Leroy
2025-01-07 15:45 ` Sebastian Andrzej Siewior
2025-01-07 8:48 ` Peter Zijlstra
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=20250107171247.gzibqLkQ@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=chenhuacai@kernel.org \
--cc=da.gomez@samsung.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=petr.pavlu@suse.com \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®