[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140929231748.GA11709@breakpoint.cc>
Date: Tue, 30 Sep 2014 01:17:48 +0200
From: Florian Westphal <fw@...len.de>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
netfilter-devel@...r.kernel.org, davem@...emloft.net,
netdev@...r.kernel.org
Subject: Re: [PATCH 32/34] netfilter: bridge: move br_netfilter out of the
core
Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Mon, 2014-09-29 at 14:39 +0200, Pablo Neira Ayuso wrote:
> > Jesper reported that br_netfilter always registers the hooks since
> > this is part of the bridge core. This harms performance for people that
> > don't need this.
> >
> > This patch modularizes br_netfilter so it can be rmmod'ed, thus,
> > the hooks can be unregistered. I think the bridge netfilter should have
> > been a separated module since the beginning, Patrick agreed on that.
> >
> > Note that this is breaking compatibility for users that expect that
> > bridge netfilter is going to be available after explicitly 'modprobe
> > bridge' or via automatic load through brctl.
> >
> > However, the damage can be easily undone by modprobing br_netfilter.
> > The bridge core also spots a message to provide a clue to people that
> > didn't notice that this has been deprecated.
> >
> > On top of that, the plan is that nftables will not rely on this software
> > layer, but integrate the connection tracking into the bridge layer to
> > enable stateful filtering and NAT, which is was bridge netfilter users
> > seem to require.
> >
> > This patch still keeps the fake_dst_ops in the bridge core, since this
> > is required by when the bridge port is initialized. So we can safely
> > modprobe/rmmod br_netfilter anytime.
> >
> > Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
> > Acked-by: Florian Westphal <fw@...len.de>
> > ---
>
> Hmm... What am I missing here ?
> # CONFIG_BRIDGE_NETFILTER is not set
Nothing. Our fault. br_nf_core.o should not be built in this case.
> $ make net/bridge/br_nf_core.o
[..]
> CC [M] net/bridge/br_nf_core.o
> net/bridge/br_nf_core.c:77:1: error: expected identifier or ‘(’ before ‘{’ token
> net/bridge/br_nf_core.c:88:12: error: redefinition of ‘br_nf_core_init’
This patch seems to fix it for me. Pablo, can you double-check?
Thanks!
Subject: [PATCH nf-next] netfilter: bridge: build br_nf_core only if required
Eric reports build failure with
CONFIG_BRIDGE_NETFILTER=n
We insist to build br_nf_core.o unconditionally, but we must only do so
if br_netfilter was enabled, else it fails to build due to
functions being defined to empty stubs (and some structure members
being defined out).
Also, BRIDGE_NETFILTER=y|m makes no sense when BRIDGE=n.
Fixes: 34666d467 (netfilter: bridge: move br_netfilter out of the core)
Reported-by: Eric Dumazet <eric.dumazet@...il.com>
Signed-off-by: Florian Westphal <fw@...len.de>
---
net/Kconfig | 2 +-
net/bridge/Makefile | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/Kconfig b/net/Kconfig
index dc5d700..d6b138e 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -177,7 +177,7 @@ config NETFILTER_ADVANCED
config BRIDGE_NETFILTER
tristate "Bridged IP/ARP packets filtering"
- depends on (BRIDGE || BRIDGE=n)
+ depends on BRIDGE
depends on NETFILTER && INET
depends on NETFILTER_ADVANCED
default m
diff --git a/net/bridge/Makefile b/net/bridge/Makefile
index 5e3eac5..fd7ee03 100644
--- a/net/bridge/Makefile
+++ b/net/bridge/Makefile
@@ -6,11 +6,12 @@ obj-$(CONFIG_BRIDGE) += bridge.o
bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \
br_ioctl.o br_stp.o br_stp_bpdu.o \
- br_stp_if.o br_stp_timer.o br_netlink.o \
- br_nf_core.o
+ br_stp_if.o br_stp_timer.o br_netlink.o
bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
+bridge-$(subst m,y,$(CONFIG_BRIDGE_NETFILTER)) += br_nf_core.o
+
obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o
bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists