Re: nftables: vmaps and atomic update

[Andreas Schultz <aschultz@tpip.net>]

Hi Robert,

Thanks for you effort.

----- On Mar 21, 2017, at 8:36 PM, Robert White rwhite@pobox.com wrote:

> On 03/21/17 16:53, Andreas Schultz wrote:
>>     delete element ip filter client_to_any { 10.180.86.22 : goto CIn_1 }
>>     delete chain ip filter CIn_1
> 
> I've verified that the problem is repeatable and that the two commands
> work separately. The problem also exists for jump verdicts.

The problem is actually even greater. If you use something like this:

    table ip filter {
	chain FORWARD {
		type filter hook forward priority 0; policy accept;
		goto CIn_1 # handle 6
	}

	chain CIn_1 {
	}
    }

Then attempting to apply a atomic update like this:

    delete rule ip filter FORWARD handle 6
    delete chain ip filter CIn_1

fails with the same error:

# nft -f del-1.nft 
del-1.nft:2:1-29: Error: Could not process rule: Device or resource busy
delete chain ip filter CIn_1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So, atomic update *ONLY* works with a "flush ruleset" followed loading all
the rules from scratch.

Andreas

> I'd suspect that there's a strict ordering that makes "the chain work
> happen first". For most cases this would make sense. Since the sets and
> the chains are owned by different parts of the kernel (the two set types
> are in kernel modules, so must be distinct from the chain handling)
> there are probably limits on the degree of atomic modification. (e.g. I
> think the sets and maps internal consistency logic _must_ be separate.)
> 
> The two commands work separately, so once the set element is gone the
> chain is just noise. So I'd rate it as annoying but probably non-trivial
> to fix.
> 
> I'd open a bug at the bug tracker site (https://bugzilla.netfilter.org/)
> and meanwhile do the chain drop separately after the set/map command.
> 
> As a cheesy workaround for scripting, you can use a here document (etc.)
> redirected into "nft -i" to do fast sequential changes.
> 
> So
> 
> nft -i <<'EOT'
> delete element ip filter client_to_any { 10.180.86.22 : goto CIn_1 }
> delete chain ip filter CIn_1
> EOT
> 
> 
> --Rob.
> 
> P.S. I'm just some guy, not a core developer or anything. I just thought
> I'd toss in a few seconds of problem analysis. 8-)