WARNING: Macros with flow control statements should be avoided #59: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:16: +#define F_0 \ +__attribute__((noinline)) \ +int f0(unsigned long a) { volatile long b = a + 16; if (a == 0) return 0; return b; } WARNING: Prefer noinline over __attribute__((noinline)) #60: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:17: +__attribute__((noinline)) \ WARNING: line length of 85 exceeds 80 columns #61: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:18: +int f0(unsigned long a) { volatile long b = a + 16; if (a == 0) return 0; return b; } ERROR: trailing statements should be on next line #61: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:18: +int f0(unsigned long a) { volatile long b = a + 16; if (a == 0) return 0; return b; } WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst #61: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:18: +int f0(unsigned long a) { volatile long b = a + 16; if (a == 0) return 0; return b; } WARNING: Macros with flow control statements should be avoided #63: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:20: +#define FN(n, prev) \ +__attribute__((noinline)) \ +int XCAT(f, n)(unsigned long a) { volatile long b = XCAT(f, prev)(a - 1); if (!b) return 0; return b + 1; } WARNING: Prefer noinline over __attribute__((noinline)) #64: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:21: +__attribute__((noinline)) \ WARNING: line length of 107 exceeds 80 columns #65: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:22: +int XCAT(f, n)(unsigned long a) { volatile long b = XCAT(f, prev)(a - 1); if (!b) return 0; return b + 1; } ERROR: trailing statements should be on next line #65: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:22: +int XCAT(f, n)(unsigned long a) { volatile long b = XCAT(f, prev)(a - 1); if (!b) return 0; return b + 1; } WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst #65: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:22: +int XCAT(f, n)(unsigned long a) { volatile long b = XCAT(f, prev)(a - 1); if (!b) return 0; return b + 1; } ERROR: Macros with complex values should be enclosed in parentheses #68: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:25: +#define F_1 F_0 FN(1, 0) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #69: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:26: +#define F_2 F_1 ^IFN(2, 1)$ ERROR: Macros with complex values should be enclosed in parentheses #69: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:26: +#define F_2 F_1 FN(2, 1) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #70: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:27: +#define F_3 F_2 ^IFN(3, 2)$ ERROR: Macros with complex values should be enclosed in parentheses #70: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:27: +#define F_3 F_2 FN(3, 2) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #71: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:28: +#define F_4 F_3 ^IFN(4, 3)$ ERROR: Macros with complex values should be enclosed in parentheses #71: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:28: +#define F_4 F_3 FN(4, 3) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #72: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:29: +#define F_5 F_4 ^IFN(5, 4)$ ERROR: Macros with complex values should be enclosed in parentheses #72: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:29: +#define F_5 F_4 FN(5, 4) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #73: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:30: +#define F_6 F_5 ^IFN(6, 5)$ ERROR: Macros with complex values should be enclosed in parentheses #73: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:30: +#define F_6 F_5 FN(6, 5) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #74: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:31: +#define F_7 F_6 ^IFN(7, 6)$ ERROR: Macros with complex values should be enclosed in parentheses #74: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:31: +#define F_7 F_6 FN(7, 6) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #75: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:32: +#define F_8 F_7 ^IFN(8, 7)$ ERROR: Macros with complex values should be enclosed in parentheses #75: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:32: +#define F_8 F_7 FN(8, 7) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #76: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:33: +#define F_9 F_8 ^IFN(9, 8)$ ERROR: Macros with complex values should be enclosed in parentheses #76: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:33: +#define F_9 F_8 FN(9, 8) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: Macros with complex values should be enclosed in parentheses #77: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:34: +#define F_10 F_9 FN(10, 9) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: Macros with complex values should be enclosed in parentheses #78: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:35: +#define F_11 F_10 FN(11, 10) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #79: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:36: +#define F_12 F_11 ^IFN(12, 11)$ ERROR: Macros with complex values should be enclosed in parentheses #79: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:36: +#define F_12 F_11 FN(12, 11) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #80: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:37: +#define F_13 F_12 ^IFN(13, 12)$ ERROR: Macros with complex values should be enclosed in parentheses #80: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:37: +#define F_13 F_12 FN(13, 12) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #81: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:38: +#define F_14 F_13 ^IFN(14, 13)$ ERROR: Macros with complex values should be enclosed in parentheses #81: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:38: +#define F_14 F_13 FN(14, 13) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #82: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:39: +#define F_15 F_14 ^IFN(15, 14)$ ERROR: Macros with complex values should be enclosed in parentheses #82: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:39: +#define F_15 F_14 FN(15, 14) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #83: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:40: +#define F_16 F_15 ^IFN(16, 15)$ ERROR: Macros with complex values should be enclosed in parentheses #83: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:40: +#define F_16 F_15 FN(16, 15) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #84: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:41: +#define F_17 F_16 ^IFN(17, 16)$ ERROR: Macros with complex values should be enclosed in parentheses #84: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:41: +#define F_17 F_16 FN(17, 16) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #85: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:42: +#define F_18 F_17 ^IFN(18, 17)$ ERROR: Macros with complex values should be enclosed in parentheses #85: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:42: +#define F_18 F_17 FN(18, 17) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #86: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:43: +#define F_19 F_18 ^IFN(19, 18)$ ERROR: Macros with complex values should be enclosed in parentheses #86: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:43: +#define F_19 F_18 FN(19, 18) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: Macros with complex values should be enclosed in parentheses #87: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:44: +#define F_20 F_19 FN(20, 19) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: Macros with complex values should be enclosed in parentheses #88: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:45: +#define F_21 F_20 FN(21, 20) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #89: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:46: +#define F_22 F_21 ^IFN(22, 21)$ ERROR: Macros with complex values should be enclosed in parentheses #89: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:46: +#define F_22 F_21 FN(22, 21) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #90: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:47: +#define F_23 F_22 ^IFN(23, 22)$ ERROR: Macros with complex values should be enclosed in parentheses #90: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:47: +#define F_23 F_22 FN(23, 22) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #91: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:48: +#define F_24 F_23 ^IFN(24, 23)$ ERROR: Macros with complex values should be enclosed in parentheses #91: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:48: +#define F_24 F_23 FN(24, 23) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #92: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:49: +#define F_25 F_24 ^IFN(25, 24)$ ERROR: Macros with complex values should be enclosed in parentheses #92: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:49: +#define F_25 F_24 FN(25, 24) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #93: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:50: +#define F_26 F_25 ^IFN(26, 25)$ ERROR: Macros with complex values should be enclosed in parentheses #93: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:50: +#define F_26 F_25 FN(26, 25) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #94: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:51: +#define F_27 F_26 ^IFN(27, 26)$ ERROR: Macros with complex values should be enclosed in parentheses #94: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:51: +#define F_27 F_26 FN(27, 26) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #95: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:52: +#define F_28 F_27 ^IFN(28, 27)$ ERROR: Macros with complex values should be enclosed in parentheses #95: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:52: +#define F_28 F_27 FN(28, 27) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #96: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:53: +#define F_29 F_28 ^IFN(29, 28)$ ERROR: Macros with complex values should be enclosed in parentheses #96: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:53: +#define F_29 F_28 FN(29, 28) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: Macros with complex values should be enclosed in parentheses #97: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:54: +#define F_30 F_29 FN(30, 29) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: Macros with complex values should be enclosed in parentheses #98: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:55: +#define F_31 F_30 FN(31, 30) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. WARNING: please, no space before tabs #99: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:56: +#define F_32 F_31 ^IFN(32, 31)$ ERROR: Macros with complex values should be enclosed in parentheses #99: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:56: +#define F_32 F_31 FN(32, 31) BUT SEE: do {} while (0) advice is over-stated in a few situations: The more obvious case is macros, like MODULE_PARM_DESC, invoked at file-scope, where C disallows code (it must be in functions). See $exceptions if you have one to add by name. More troublesome is declarative macros used at top of new scope, like DECLARE_PER_CPU. These might just compile with a do-while-0 wrapper, but would be incorrect. Most of these are handled by detecting struct,union,etc declaration primitives in $exceptions. Theres also macros called inside an if (block), which "return" an expression. These cannot do-while, and need a ({}) wrapper. Enjoy this qualification while we work to improve our heuristics. ERROR: trailing whitespace #116: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:73: +/* $ ERROR: trailing whitespace #117: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:74: + * Check we actually honor stack limits (33 * 16 = 528 > 512 = MAX_STACK_DEPTH). $ WARNING: line length of 81 exceeds 80 columns #117: FILE: tools/testing/selftests/bpf/progs/test_global_func_deep_stack.c:74: + * Check we actually honor stack limits (33 * 16 = 528 > 512 = MAX_STACK_DEPTH). total: 36 errors, 34 warnings, 0 checks, 97 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile Commit 14392363f016 ("bpf: Add deep call stack selftests") has style problems, please review. NOTE: Ignored message types: ALLOC_SIZEOF_STRUCT BAD_REPORTED_BY_LINK CAMELCASE COMMIT_LOG_LONG_LINE FILE_PATH_CHANGES GIT_COMMIT_ID MACRO_ARG_REUSE NO_AUTHOR_SIGN_OFF NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS.