On Wed, 2021-06-23 at 18:53 +0200, Pavel Machek wrote: > Hi! > > > > > From: Paolo Abeni <pabeni@xxxxxxxxxx> > > > > > > > > [ Upstream commit 61e710227e97172355d5f150d5c78c64175d9fb2 ] > > > > > > > > warn_bad_map() produces a kernel WARN on bad input coming > > > > from the network. Use pr_debug() to avoid spamming the system > > > > log. > > > > > > So... we switched from WARN _ONCE_ to pr_debug, as many times as we > > > detect the problem. > > > > > > Should this be pr_debug_once? > > > > Thank you for double checking this! > > > > In the MPTCP code, we use pr_debug() statements as a debug tool, e.g. > > when enabled, it could print per-packet info with no restriction. > > > > There are (a few) similar use in the plain TCP code. > > > > pr_debug() is not supposed to be enabled on any production system, > > while the WARN_ONCE could trigger automated tools for irrelevant > > network noise. > > Correct me if I'm wrong, but I believe pr_debug will result in > messages being stored in the dmesg buffer, even on production > systems. If DYNAMIC_DEBUG is enabled, and the system administator explicitly enables the relevant debug message writing suitable data in /sys/kernel/debug/dynamic_debug/control, yes, the message will be printed on dmsg. With DYNAMIC_DEBUG disabled, patching the kernel and defining the DEBUG macro in the net/mptcp/protocol.c file you will get again the debug message. Neither of the above fit productions systems IMHO, and I'm not aware of other options to trigger the relevant debug message. I personally have CONFIG_DYNAMIC_DEBUG=y in my kconfig and I enable the relevant debug message as needed in my devel activity. Cheers, Paolo
