[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20161215093224.23126-1-jslaby@suse.cz>
Date: Thu, 15 Dec 2016 10:32:24 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org, Jiri Slaby <jslaby@...e.cz>
Subject: [PATCH] ratelimit: fix WARN_ON_RATELIMIT return value
The macro is to be used similarly as WARN_ON as:
if (WARN_ON_RATELIMIT(condition, state))
do_something();
One would expect only 'condition' to affect the 'if', but
WARN_ON_RATELIMIT does internally only:
WARN_ON((condition) && __ratelimit(state))
So the 'if' is affected by the ratelimiting state too. Fix this by
returning 'condition' in any case.
Note that nobody uses WARN_ON_RATELIMIT yet, so there is nothing to
worry about. But I was about to use it and was a bit surprised.
Signed-off-by: Jiri Slaby <jslaby@...e.cz>
---
include/linux/ratelimit.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index 57c9e0622a38..56375edf2ed2 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -77,8 +77,11 @@ extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#ifdef CONFIG_PRINTK
-#define WARN_ON_RATELIMIT(condition, state) \
- WARN_ON((condition) && __ratelimit(state))
+#define WARN_ON_RATELIMIT(condition, state) ({ \
+ bool __rtn_cond = !!(condition); \
+ WARN_ON(__rtn_cond && __ratelimit(state)); \
+ __rtn_cond; \
+})
#define WARN_RATELIMIT(condition, format, ...) \
({ \
--
2.11.0
Powered by blists - more mailing lists