cpp has no intrinsic protection against macro arg side-effects, so to
compensate, checkpatch is paranoid:

  CHECK: Macro argument reuse '_var' - possible side-effects?

Allow an author to suppress these warnings on _var by adding
'__chkp_no_side_effects(_var)' to the body of macros which trigger
that warning.  This may reduce blowouts in CI pipelines.

Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
 include/linux/compiler.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 64ff73c533e5..96f6bfbd4088 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -379,6 +379,18 @@ static inline void *offset_to_ptr(const int *off)
  */
 #define prevent_tail_call_optimization()	mb()
 
+/*
+ * tell checkpatch --strict that you know the named args (a subset of
+ * the containing macro's args) are safe for multiple expansions.
+ *
+ * Prefer ({ typeof ..}) or do{}while(0) when they work.  They would
+ * not work on module_param_named(name, value, type, perm), or on a
+ * locally useful "for_simplicity()" macro.
+ *
+ * NB: use at top of macro body, omit trailing semicolon.
+ */
+#define __chkp_no_side_effects(...)  /* checkpatch "annotation" helper */
+
 #include <asm/rwonce.h>
 
 #endif /* __LINUX_COMPILER_H */
-- 
2.51.0

On Sat, 25 Oct 2025 at 14:15, Jim Cromie <jim.cromie@gmail.com> wrote:
>
> Allow an author to suppress these warnings on _var by adding
> '__chkp_no_side_effects(_var)' to the body of macros which trigger
> that warning.  This may reduce blowouts in CI pipelines.

How about just not doing that checkpatch thing at all if it causes problems?

Seriously, I think checkpatch often causes more problems than it
fixes. If it then causes us to write even uglier macros - and it's not
like our macros are pretty in general - it really is just causing
pain.

I think we should cut down checkpatch to things that are obvious and
real issues. Not things that then cause people to make code worse.

                 Linus