Re: shift by n bits while performing '--restore-mark'

Hi Florian, Do these patches looks acceptable for the mainline stream? Any code comments will be appreciated ! Regards, Jack-- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH RFC 0/4] net: add bpfilter

> I see several possible areas of contention: > > 1) If you aim for a non-feature-complete support of iptables rules, it >will create confusion to the users. Right, you need full feature parity to be avoid ending up having to maintain two implementations. It seems uncontroversial that BPF

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, 19 Feb 2018, Florian Westphal wrote: > David Miller wrote: > > > > Florian, first of all, the whole "change the iptables binary" idea is > > a non-starter. For the many reasons I have described in the various > > postings I have made today. > > > > It

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 18:14:11 +0100 > > > OK, so reading between the lines you're saying that nftables project > > has failed to provide an adequate successor to iptables? > > Whilst it is great that the atomic table

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 01:41:29PM -0500, David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 19:05:51 +0100 > > > On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: > >> From: Phil Sutter > >> Date: Mon, 19 Feb 2018 18:14:11 +0100 >

Re: [PATCH RFC PoC 0/3] nftables meets bpf

On 02/19/2018 05:37 PM, Pablo Neira Ayuso wrote: [...] > * Simplified infrastructure: We don't need the ebpf verifier complexity > either given we trust the code we generate from the kernel. We don't > need any complex userspace tooling either, just libnftnl and nft > userspace binaries. >

Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure

From: Pablo Neira Ayuso Date: Mon, 19 Feb 2018 17:37:06 +0100 > From nf_tables_newrule(), this calls nft_jit_rule() that transforms > our internal expression structure layout to abstract syntax tree, then > we walk over this syntax tree to generate the BPF instructions that

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 19:37:30 +0100 > I was speaking of actual *users* as in indiiduals running their own > systems, companies running their own servers/datacenter. The fact that > some ISP (or its supplier) decisdes that one of my IP packets is routed

Re: [PATCH RFC 0/4] net: add bpfilter

From: Arturo Borrero Gonzalez Date: Mon, 19 Feb 2018 19:06:12 +0100 > Yes, probably major datacenters (google? facebook?, amazon?) they > don't even care about what Debian is doing, since they are crafting > their own distro anyway. But there are *a lot* of other people

Re: [PATCH RFC 0/4] net: add bpfilter

From: Phil Sutter Date: Mon, 19 Feb 2018 19:05:51 +0100 > Hi David, > > On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: >> From: Phil Sutter >> Date: Mon, 19 Feb 2018 18:14:11 +0100 >> >> > OK, so reading between the lines you're saying that nftables

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 12:29:08PM -0500, David Miller wrote: > People with an Android phone in their pocket is using iptables, and > the overhead and performance of those rules really does matter. It > determines how long your battery life is, etc. I am not the android expert.

Re: [PATCH RFC 0/4] net: add bpfilter

On 19 February 2018 at 16:36, David Miller wrote: > > In my opinion, any resistence to integration with eBPF and XDP will > lead to even less adoption of netfilter as a technology. > > Therefore my plan is to move everything to be integrated around these > important core

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 18:14:11 +0100 > > > OK, so reading between the lines you're saying that nftables project > > has failed to provide an adequate successor to iptables? > > Whilst it

Re: [PATCH RFC 0/4] net: add bpfilter

On 19 February 2018 at 16:27, David Miller wrote: > From: Florian Westphal > Date: Mon, 19 Feb 2018 16:15:55 +0100 > >> Would you be willing to merge nftables into kernel tools directory >> then? > > Did you miss the part where I explained that people

Re: [PATCH RFC 0/4] net: add bpfilter

On 19 February 2018 at 16:36, David Miller wrote: > > I think netfilter is at a real crossroads right now. > I don't think so. The Netfilter Project and the Netfilter Community already "agreed" on nftables and we are working on it. But this isn't a secret, right? We have

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote: > > Why is it practical to replace your kernel but not practical to replace > > a small userspace tool running on top of it? > > The container is just userspace components. Those are really baked in > and are never

Re: [PATCH nft v2] nftables: basic support for extended netlink errors

Hi Florian, On Sun, Feb 18, 2018 at 10:44:18AM +0100, Florian Westphal wrote: > Recent kernels gained ability to emit error string back to userspace to > improve error reporting. > > At this time, as nftables kernel side doesn't generate such error > messages, so this will always show 'unknown

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 18:20:40 +0100 > It's like with any migration. People were using ipchains for a long > time even after iptables existed. Many people simply don't care > about packet filter performance. It's only a small fraction of their >

Re: [PATCH nf] netfilter: IDLETIMER: be syzkaller friendly

On Fri, Feb 16, 2018 at 07:36:28PM -0800, Eric Dumazet wrote: > From: Eric Dumazet > > We had one report from syzkaller [1] > > First issue is that INIT_WORK() should be done before mod_timer() > or we risk timer being fired too soon, even with a 1 second timer. > > Second

Re: [PATCH iptables] extensions: connmark: remove non-working translation

On Mon, Feb 19, 2018 at 12:47:55PM +0100, Florian Westphal wrote: > ... and return 0 so output reflects that no translation was performed. > > iptables-translate -A I -j CONNMARK --save-mark --mask 0xff > nft # -A I -j CONNMARK --save-mark --mask 0xff > > The translation that was performed: >

Re: [PATCH iptables] extensions: mark: prefer plain 'set' over 'set mark and'

On Mon, Feb 19, 2018 at 12:46:45PM +0100, Florian Westphal wrote: > adding a test case for MARK --set-mark 0 fails with > exp: nft add rule ip mangle OUTPUT counter meta mark set 0x0 > res: nft add rule ip mangle OUTPUT counter meta mark set mark and 0x0 > > This translation isn't wrong, but

Re: [PATCH RFC 0/4] net: add bpfilter

From: Phil Sutter Date: Mon, 19 Feb 2018 18:14:11 +0100 > OK, so reading between the lines you're saying that nftables project > has failed to provide an adequate successor to iptables? Whilst it is great that the atomic table update problem was solved, I think the emphasis on

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:36:51AM -0500, David Miller wrote: > nftables has been proported as "better" for years, yet large > institutions did not migrate to it. In fact, they explicitly > disabled NFTABLES in their kernel config. It's like with any migration. People were using

Re: [PATCH RFC 0/4] net: add bpfilter

From: Phil Sutter Date: Mon, 19 Feb 2018 18:09:39 +0100 > What puzzles me about your argumentation is that you seem to propose for > the kernel to cover up flaws in userspace. Spinning this concept further > would mean that if there would be an old bug in iproute2 we should think >

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:44:59AM -0500, David Miller wrote: > From: Harald Welte > Date: Mon, 19 Feb 2018 16:38:08 +0100 > > > On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote: > >> > Would you be willing to merge nftables into kernel tools

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote: > From: Harald Welte > Date: Mon, 19 Feb 2018 16:27:46 +0100 > > > On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote: > > > >> Florian, first of all, the whole "change the iptables binary"

[PATCH RFC PoC 0/3] nftables meets bpf

Hi! The following patchset is a PoC to add generic infrastructure to jit nftables to bpf. Rationale is the following: nft --> netlink --> nf_tables -> intermediate representation --> bpf The idea is to convert our internal nf_tables structure representation to an abstract syntax tree (our

[PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure

>From nf_tables_newrule(), this calls nft_jit_rule() that transforms our internal expression structure layout to abstract syntax tree, then we walk over this syntax tree to generate the BPF instructions that are placed in the rule jit buffer. From the commit phase, collect all jit buffers, place

[PATCH RFC 2/3] netfilter: add ast to target transformation

This patch adds the generic infrastructure is used to describe the transformation from abstract syntax tree to target internal representation. The target has to define the transformation callbacks: struct nft_ast_xfrm_desc { const struct nft_ast_proto_desc *proto_desc; const struct

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 16:38:08 +0100 > On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote: >> > Would you be willing to merge nftables into kernel tools directory >> > then? >> >> Did you miss the part where I explained that people explicitly

Re: [PATCH RFC 0/4] net: add bpfilter

From: Jan Engelhardt Date: Mon, 19 Feb 2018 16:37:57 +0100 (CET) > On Monday 2018-02-19 16:32, David Miller wrote: > >>From: Harald Welte >>Date: Mon, 19 Feb 2018 16:23:21 +0100 >> >>> Also, as long as legacy ip_tables/x_tables is still in the kernel, you

Re: [PATCH RFC 0/4] net: add bpfilter

Dear David, On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote: > > Would you be willing to merge nftables into kernel tools directory > > then? > > Did you miss the part where I explained that people explicitly disable > NFTABLES in their kernel configs in most if not all large

Re: [PATCH RFC 0/4] net: add bpfilter

On Monday 2018-02-19 16:32, David Miller wrote: >From: Harald Welte >Date: Mon, 19 Feb 2018 16:23:21 +0100 > >> Also, as long as legacy ip_tables/x_tables is still in the kernel, you >> can still run your old userspace against that old implementation in the >> kernel. >

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 16:23:21 +0100 >> Like it or not iptables ABI based filtering is going to be in the data >> path for many years if not a decade or more to come. > > I beg to differ. For some people, yes. but then, as Florian points > out, they

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 16:23:21 +0100 > Also, as long as legacy ip_tables/x_tables is still in the kernel, you > can still run your old userspace against that old implementation in the > kernel. But without offloading, and the various other benefits

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 16:27:46 +0100 > On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote: > >> Florian, first of all, the whole "change the iptables binary" idea is >> a non-starter. For the many reasons I have described in the various >>

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 09:44:51AM -0500, David Miller wrote: > I see talk about "just replacing the iptables binary". > > A long time ago in a galaxy far far away, that would be a reasonable > scheme. But that kind of approach won't work in the realities of > today. > > You aren't

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote: > Florian, first of all, the whole "change the iptables binary" idea is > a non-starter. For the many reasons I have described in the various > postings I have made today. > > It is entirely impractical. Why is it

Re: [PATCH RFC 0/4] net: add bpfilter

From: Florian Westphal Date: Mon, 19 Feb 2018 16:20:23 +0100 > See my other mail, where I explained, in great detail, the problems > of the xtables UAPI. As the person who wrote the bpfilter UAPI parser for this, you don't need to explain this to me. But it's not going

Re: [PATCH RFC 0/4] net: add bpfilter

From: Florian Westphal Date: Mon, 19 Feb 2018 16:15:55 +0100 > Would you be willing to merge nftables into kernel tools directory > then? Did you miss the part where I explained that people explicitly disable NFTABLES in their kernel configs in most if not all large datacenters?

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > From: Florian Westphal > Date: Mon, 19 Feb 2018 15:53:14 +0100 > > > Sure, but looking at all the things that were added to iptables > > to alleviate some of the issues (ipset for instance) show that we need a > > meaningful re-design

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > From: Florian Westphal > Date: Mon, 19 Feb 2018 15:59:35 +0100 > > > David Miller wrote: > >> It also means that the scope of developers who can contribute and work > >> on the translater is much larger. > > > >

Re: [PATCH RFC 0/4] net: add bpfilter

From: Florian Westphal Date: Mon, 19 Feb 2018 15:59:35 +0100 > David Miller wrote: >> It also means that the scope of developers who can contribute and work >> on the translater is much larger. > > How so? Translator is in userspace in nftables case too?

Re: [PATCH RFC 0/4] net: add bpfilter

From: Florian Westphal Date: Mon, 19 Feb 2018 15:53:14 +0100 > Sure, but looking at all the things that were added to iptables > to alleviate some of the issues (ipset for instance) show that we need a > meaningful re-design of how things work conceptually. As you said iptables

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > From: Daniel Borkmann > Date: Mon, 19 Feb 2018 13:03:17 +0100 > > > Thought was that it would be more suitable to push all the complexity of > > such translation into user space which brings couple of additional > > advantages >

Re: [PATCH RFC 0/4] net: add bpfilter

From: Daniel Borkmann Date: Mon, 19 Feb 2018 13:03:17 +0100 > Thought was that it would be more suitable to push all the complexity of > such translation into user space which brings couple of additional advantages > as well: the translation can become very complex and thus

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > > How many of those wide-spread applications are you aware of? The two > > projects you have pointed out (docker and kubernetes) don't. As the > > assumption that many such tools would need to be supported drives a lot > > of the design decisions, I

Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte Date: Mon, 19 Feb 2018 13:52:18 +0100 >> Right, having a custom iptables, libiptc or LD_PRELOAD approach would work >> as well of course, but it still wouldn't address applications that have >> their own custom libs programmed against iptables uapi

Re: [PATCH RFC 0/4] net: add bpfilter

Hi Daniel, On Mon, Feb 19, 2018 at 01:03:17PM +0100, Daniel Borkmann wrote: > Hi Harald, > > On 02/17/2018 01:11 PM, Harald Welte wrote: > [...] > >> As rule translation can potentially become very complex, this is performed > >> entirely in user space. In order to ease deployment,

[PATCH iptables] extensions: connmark: remove non-working translation

... and return 0 so output reflects that no translation was performed. iptables-translate -A I -j CONNMARK --save-mark --mask 0xff nft # -A I -j CONNMARK --save-mark --mask 0xff The translation that was performed: nft add rule ip mangle PREROUTING counter meta mark set ct mark and 0xff will

[PATCH iptables] extensions: mark: prefer plain 'set' over 'set mark and'

adding a test case for MARK --set-mark 0 fails with exp: nft add rule ip mangle OUTPUT counter meta mark set 0x0 res: nft add rule ip mangle OUTPUT counter meta mark set mark and 0x0 This translation isn't wrong, but unneccessarily complex, so change order to first check if mask bits are all

Re: [PATCH nf 1/2] netfilter: ipt_CLUSTERIP: put config struct if we can't increment ct refcount

kbuild test robot <l...@intel.com> wrote: > Hi Florian, > > I love your patch! Perhaps something to improve: > > [auto build test WARNING on nf/master] > > url: > https://github.com/0day-ci/linux/commits/Florian-Westphal/netfilter-ipt_CLUSTERIP-two-more-fixes/2

Re: [PATCH nf 1/2] netfilter: ipt_CLUSTERIP: put config struct if we can't increment ct refcount

Hi Florian, I love your patch! Perhaps something to improve: [auto build test WARNING on nf/master] url: https://github.com/0day-ci/linux/commits/Florian-Westphal/netfilter-ipt_CLUSTERIP-two-more-fixes/20180219-090236 base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git