On 04/25/2017 10:06 AM, Jakub Kicinski wrote:
As we propagate extended ack reporting throughout various paths in
the kernel it may happen that the same function is called with the
extended ack parameter passed as NULL. Make the NL_SET_ERR_MSG()
macro simply print the message to the logs if that happens.
Signed-off-by: Jakub Kicinski <[email protected]>
---
include/linux/netlink.h | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 8d2a8924705c..b59cfbf2e2c7 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -86,10 +86,14 @@ struct netlink_ext_ack {
* Currently string formatting is not supported (due
* to the lack of an output buffer.)
*/
-#define NL_SET_ERR_MSG(extack, msg) do { \
- static const char _msg[] = (msg); \
- \
- (extack)->_msg = _msg; \
+#define NL_SET_ERR_MSG(extack, msg) do { \
+ struct netlink_ext_ack *_extack = (extack); \
+ static const char _msg[] = (msg); \
+ \
+ if (_extack) \
+ _extack->_msg = _msg; \
+ else \
+ pr_info("%s\n", _msg); \
} while (0)
extern void netlink_kernel_release(struct sock *sk);
Probably makes sense to have a NL_MOD_SET_ERR_MSG(), which
then also prepends a KBUILD_MODNAME ": " string to the
message (similar to pr_*()), so that it's easier to identify
whether the error came from a specific driver or rather
common core code?
