netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Jan Engelhardt <jengelh@medozas.de>,
	David Miller <davem@davemloft.net>,
	ajax@redhat.com, linux-kernel@vger.kernel.org, davej@redhat.com,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] net: Remove a noisy printk
Date: Mon, 15 Dec 2008 13:23:08 +0100	[thread overview]
Message-ID: <49464C2C.6030009@trash.net> (raw)
In-Reply-To: <alpine.DEB.2.00.0812142056520.2621@blackhole.kfki.hu>

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.



  reply	other threads:[~2008-12-15 12:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1229033625-30825-1-git-send-email-ajax@redhat.com>
2008-12-12  4:32 ` [PATCH] net: Remove a noisy printk David Miller
2008-12-13 22:13   ` Jan Engelhardt
2008-12-14 17:09     ` Jozsef Kadlecsik
2008-12-14 18:06       ` Jan Engelhardt
2008-12-14 20:15         ` Jozsef Kadlecsik
2008-12-15 12:23           ` Patrick McHardy [this message]
2008-12-15 13:25             ` Jozsef Kadlecsik
2008-12-15 13:32               ` Patrick McHardy
2008-12-14 20:03       ` Dave Jones
2008-12-16 19:59         ` Jozsef Kadlecsik
2008-12-16 20:03           ` Jan Engelhardt
2008-12-16 20:00         ` Jan Engelhardt
2008-12-17  8:26           ` Jozsef Kadlecsik
2008-12-19  1:21         ` Rusty Russell
2009-01-12  5:02           ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49464C2C.6030009@trash.net \
    --to=kaber@trash.net \
    --cc=ajax@redhat.com \
    --cc=davej@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jengelh@medozas.de \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).