All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
	netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/2 nf-next] net: bridge: don't register netfilter call_iptables hooks by default
Date: Wed, 17 Sep 2014 14:42:30 +0200	[thread overview]
Message-ID: <20140917124230.GJ14006@breakpoint.cc> (raw)
In-Reply-To: <20140917121530.GA3750@salvia>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > As its not possible to register hooks from bh context (grabs mutex)
> > its scheduled via workqueue.
> 
> My main concern with this approach is that we may let packets go
> through unfiltered for some little time until the worker thread has
> the chance to register the hooks.

They are supposed to be dropped until hook is there.
However, Nikolay Alexandrov just (correctly...) pointed out to me via irc that this mutex
abuse is against the rules (lock/unlock in different threads!).

So, please toss this series.

> Alternatives that I see for these are:
> * pr_info to indicate the br_netfilter enable by default is
>   deprecated. Similar to your small patch 2/2, but it will take quite
>   some time until we can finally change this to zero.

Right.  I had planned to send a revert for patch 1 at some point,
plus a change to default to 0.

> * I think we can unregister the hooks when we notice that all
>   bridge-nf-call-*tables are zero from the sysctl. We register them if
>   any of them becomes 1 again.

Thats what I thought, but we now also have per-bridge sysfs knobs,
i.e. sysctl could be 0 and someone enabling br42->call_iptables ....

Its doable, but it gets ugly.
I don't think its worth the pain to care about "sometimes
enabled/disabled".

      reply	other threads:[~2014-09-17 12:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 15:47 [PATCH 1/2 nf-next] net: bridge: don't register netfilter call_iptables hooks by default Florian Westphal
2014-09-16 15:47 ` [PATCH 2/2 nf-next] net: bridge: deprecate call_iptables=1 default Florian Westphal
2014-09-17 12:15 ` [PATCH 1/2 nf-next] net: bridge: don't register netfilter call_iptables hooks by default Pablo Neira Ayuso
2014-09-17 12:42   ` Florian Westphal [this message]

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=20140917124230.GJ14006@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.