lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Apr 2017 11:12:11 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Jakub Kicinski <jakub.kicinski@...ronome.com>, netdev@...r.kernel.org CC: davem@...emloft.net, johannes@...solutions.net, dsa@...ulusnetworks.com, alexei.starovoitov@...il.com, bblanco@...il.com, john.fastabend@...il.com, kubakici@...pl, oss-drivers@...ronome.com Subject: Re: [RFC 1/4] netlink: make extended ACK setting NULL-friendly 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 <jakub.kicinski@...ronome.com> > --- > 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?
Powered by blists - more mailing lists