Messages in this thread | | | Date | Mon, 15 Dec 2008 13:23:08 +0100 | From | Patrick McHardy <> | Subject | Re: [PATCH] net: Remove a noisy printk |
| |
Jozsef Kadlecsik wrote: > On Sun, 14 Dec 2008, Jan Engelhardt wrote: > >>> In a >normal< system one usually does not use raw sockets. So if a root >>> process do use raw socket, at least netfilter sends a notification and >>> there's a chance that someone take notice it by checking the kernel logs. >>> [...] >>> But should we remove them due to nuisances on >test< systems? >>> >>> Rather make it a kernel compile option but do not remove. >> This warning is in the conntrack calling code. Iff you play with >> raw sockets and do something wrong, the generic network code >> should barf IMHO, not nf_conntrack, and not [nf_conntrack_ipv4 only]. > > It is not about doing something wrong at using raw sockets - it's about > using raw sockets. > > I'm not quite convinced the generic network code should warn about raw > sockets. I believe it belongs to the security-related subsystems - > netfilter and (or) the security frameworks. [But as netfilter is much more > widely used, the 'or' is just theoretical.)
I agree that it doesn't belong to the generic networking code. But the way its handled in netfilter is far from perfect as well. Currently multiple modules will spam the ringbuffer repeatedly, but offer no possibility to change anything in the behaviour of how these packets are treated. Unfortunately we can't handle this in the ruleset (which is exactly the reason why we're spamming the ringbuffer), so how about we add a module option controlling how to treat those packets and remove the printk?
In the case of conntrack I would even argue that the message makes no sense at all since tracking doesn't matter as long as the state isn't used. And for that the table code can warn or offer controls.
| |