[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVWBpsC4kvMuMQsc@salvia>
Date: Thu, 30 Sep 2021 11:21:42 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: netfilter-devel@...r.kernel.org, davem@...emloft.net,
netdev@...r.kernel.org, kuba@...nel.org, lukas@...ner.de,
kadlec@...filter.org, fw@...len.de, ast@...nel.org,
edumazet@...gle.com, tgraf@...g.ch, nevola@...il.com,
john.fastabend@...il.com, willemb@...gle.com
Subject: Re: [PATCH nf-next v5 0/6] Netfilter egress hook
On Thu, Sep 30, 2021 at 09:33:23AM +0200, Daniel Borkmann wrote:
> On 9/30/21 9:19 AM, Pablo Neira Ayuso wrote:
[...]
> > Why do you need you need a sysctl knob when my proposal is already
> > addressing your needs?
>
> Well, it's not addressing anything ... you even mention it yourself "arguably,
> distributors might decide to compile nf_tables_netdev built-in".
I said distributors traditionally select the option that we signal to
them, which is to enable this as module. We can document this in
Kconfig. I think distributors should select whatever is better for
their needs.
Anyway, I'll tell you why module blacklisting is bad: It is a hammer,
it is a band aid to a problem. Blacklisting is just making things
worst because it makes some people believe that something is
unfixable. Yes, it took me a while to figure out.
We already entered the let's bloat the skbuff for many years already,
this is stuffing one more bit into the skbuff just because maybe users
might break an existing setup when they load new rules to the new
netfilter egress hook.
Probably the sysctl for this new egress hook is the way to go as you
suggest.
Thanks.
Powered by blists - more mailing lists