Re: [PATCH v8 42/43] dyndbg: add DEBUG-biased fallback stubs for _dynamic_func_call_cls

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Commit message and code mismatch regarding macro evaluation and return type.
--

commit 540d64bf950ba97fca84806f776637334569e3d7
Author: Jim Cromie [off-list ref]
Subject: dyndbg: add DEBUG-biased fallback stubs for _dynamic_func_call_cls

This commit adds fallback stubs for the _dynamic_func_call_cls family of
macros when dynamic debug is disabled. It ensures that subsystems wrapping
these functions do not fail to build due to implicit declarations.

Closes: https://lore.kernel.org/oe-kbuild-all/202605201408.x1sHT6fx-lkp@intel.com/ (local)

If DEBUG is not defined, they use an if (0) statement-expression to compile
out the call while returning 0, achieving zero overhead while maintaining
compile-time argument checking.

[ ... ]

+#else
+#define _dynamic_func_call_cls(cls, fmt, func, ...)		\
+	do { if (0) func(NULL, ##__VA_ARGS__); } while (0)
+#define _dynamic_func_call_cls_no_desc(cls, fmt, func, ...)	\
+	do { if (0) func(__VA_ARGS__); } while (0)
+#endif

[Severity: Medium]
Is there a discrepancy here between the commit message and the implementation?

The commit message states that the fallback stubs in 
include/linux/dynamic_debug.h use a statement-expression to return 0.
However, the actual implementation of _dynamic_func_call_cls uses a
do-while(0) loop, which evaluates to void rather than 0.

Since these macros are typically used as statements, evaluating to void seems
functionally correct for compilation. Could the commit message be updated to
accurately reflect the do-while(0) implementation to avoid confusion?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260905-dd-cmap-part2-clean-v8-0-a4cc0674f6fd@gmail.com?part=42