From: Florian Westphal <fw@strlen.de>
To: Florian Westphal <fw@strlen.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v2 nf-next 0/9] netfilter: don't copy initns hooks to new namespaces
Date: Mon, 2 Nov 2015 14:00:58 +0100 [thread overview]
Message-ID: <20151102130058.GA7484@breakpoint.cc> (raw)
In-Reply-To: <20151029221303.GE18062@breakpoint.cc>
Florian Westphal <fw@strlen.de> wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > We can probably register the hooks from ctnetlink based on what we
> > already have, ie. if nf_conntrack_ipv4 is loaded and someone runs
> > conntrack -E (or whatever custom application to listen to events),
> > then we get the hooks registered.
>
> Right, thats what the RFC patch I sent does, it asks all the loaded
> ones to register the hooks on ctnetlink bind (i.e. conntrack -L doesn't
> register anything either, but I'm not sure thats what we would want here
> since -L is just 'show me all conntrack entries' and there are none,
> it seems wrong to take a display request as a hint that conntrack should
> be enabled.
>
> > On top of that, assuming someone modprobes nf_conntrack_ipv6 later on,
> > we'll have to iterate over the list of netns available and register
> > the hooks if anyone is already listening to events as well.
>
> Hmm, I wonder if this is doable without adding any additional module
> dependencies... I'll check if its feasible.
So the current plan is to add a 'notification' call to
ctnetlink_glue_hook, i.e.
.newproto = ctnl_newproto,
and then, from nf_ct_l3proto_register(), do:
nfnl_ct = rcu_dereference(nfnl_ct_hook);
if (nfnl_ct)
nfnl_ct->newproto(nfproto);
This would kick ctnetlink without adding a module dependency.
Downside is that ctnetlink would need some additional logic to
make newproto() do nothing unless we saw at least on bind attempt
before (otherwise we'd always register the hooks for a new conntracker
in all the network namespaces).
For that we'd have to iterate over all the network namespaces we have
and check a per-netns knob if ctnetlink was requested at some point in the
past.
It might be acceptable though since nf_ct_l3proto_register is only
called from module init hooks.
What do you think?
> > Remember we also now also have nfnetlink_log and _queue integration
> > with conntrack, there we should register the hooks too in case the
> > userspace application.
>
> Ugh, I forgot. I don't see how this is fixable at the moment
> Userspace has to set _CFG_F_CONNTRACK flag but I am not (yet) convinced
> that a mere presence of this flag should force register of the conntrack
> hooks.
>
> We'd also need yet another exported pointer-hook to prevent direct
> module dependencies from nfqueue/nflog to conntrack. Seems best way
> would be to add a "passive" register request function to
>
> struct nfnl_ct_hook {
> ...
> }
>
> in nf_conntrack_netlink.c
>
> [ passive in the sense of 'register hooks of all nf_conntrack_nfproto
> modules loaded, but don't grab refcount on those modules and don't
> modprobe anything ]
This is less intrusive than I thought and should not affect any hotpath,
we can check at config time wheter this feature is wanted and then
nfnl_ct_hook->register_hooks(net)
next prev parent reply other threads:[~2015-11-02 13:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-23 10:43 [PATCH v2 nf-next 0/9] netfilter: don't copy initns hooks to new namespaces Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 1/9] netfilter: ingress: don't use nf_hook_list_active Florian Westphal
2015-11-06 18:33 ` Pablo Neira Ayuso
2015-10-23 10:43 ` [PATCH v2 nf-next 2/9] netfilter: add and use nf_ct_netns_get/put Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 3/9] netfilter: conntrack: register hooks in netns when needed by ruleset Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 4/9] netfilter: xtables: don't register xt hooks in namespace at init time Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 5/9] netfilter: defrag: only register defrag functionality if needed Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 6/9] netfilter: nat: add dependencies on conntrack module Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 7/9] netfilter: bridge: register hooks only when bridge is added Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 8/9] netfilter: don't call nf_hook_state_init/_hook_slow unless needed Florian Westphal
2015-10-23 10:43 ` [PATCH v2 nf-next 9/9] nftables: add conntrack dependencies for nat/masq/redir expressions Florian Westphal
2015-10-26 22:55 ` [PATCH v2 nf-next 0/9] netfilter: don't copy initns hooks to new namespaces Pablo Neira Ayuso
2015-10-26 23:09 ` Florian Westphal
2015-10-27 16:35 ` Florian Westphal
2015-10-28 12:39 ` Jan Engelhardt
2015-10-29 20:35 ` Pablo Neira Ayuso
2015-10-29 22:13 ` Florian Westphal
2015-11-02 13:00 ` Florian Westphal [this message]
2015-11-24 10:27 ` Pablo Neira Ayuso
2015-11-24 10:59 ` Florian Westphal
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=20151102130058.GA7484@breakpoint.cc \
--to=fw@strlen.de \
--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 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).