nftables: lockout with 0008split_tables_0 test

[Phil Sutter <phil@nwl.cc>]

Hi,

This is about tests/shell/testcases/nft-f/0008split_tables_0, which adds
the following simple ruleset:

| table inet filter {
|         chain ssh {
|                 type filter hook input priority 0; policy accept;
|                 tcp dport ssh accept;
|         }
| }
| 
| table inet filter {
|         chain input {
|                 type filter hook input priority 1; policy drop;
|         }
| }

If applied, it kills my SSH connection. :(

I changed the ruleset for debugging purposes to this one:

| table inet filter {
|         chain ssh {
|               type filter hook input priority 0; policy accept;
| 		meta nftrace set 1
| 		accept
|         }
| }
| 
| table inet filter {
|         chain input {
|               type filter hook input priority 1; policy drop;
| 		meta nftrace set 1
|         }
| }

So I've changed the rule in chain 'ssh' to allow everything and enabled
tracing. Looking at trace output, I see this:

| trace id 4a1d1b92 inet filter ssh packet: iif "eth0" ether saddr fe:07:ef:9f:d5:dd ether daddr 52:54:ff:12:34:56 ip6 saddr fec0:42::1 ip6 daddr fec0:42::24 ip6 dscp 0x02 ip6 ecn not-ect ip6 hoplimit 64 ip6 flowlabel 871503 ip6 length 280 tcp sport 59068 tcp dport ssh tcp flags == 0x19 tcp window 1412 
| trace id 4a1d1b92 inet filter ssh rule nftrace set 1 (verdict continue)
| trace id 4a1d1b92 inet filter ssh rule accept (verdict accept)
| trace id 4a1d1b92 inet filter input packet: iif "eth0" ether saddr fe:07:ef:9f:d5:dd ether daddr 52:54:ff:12:34:56 ip6 saddr fec0:42::1 ip6 daddr fec0:42::24 ip6 dscp 0x02 ip6 ecn not-ect ip6 hoplimit 64 ip6 flowlabel 871503 ip6 length 280 tcp sport 59068 tcp dport ssh tcp flags == 0x19 tcp window 1412 
| trace id 4a1d1b92 inet filter input rule nftrace set 1 (verdict continue)
| trace id 4a1d1b92 inet filter input verdict continue 
| trace id 4a1d1b92 inet filter input 

It shows that given packet traverses both chains instead of only the
first one as I would have expected and therefore drop policy of chain
'input' applies instead of the 'accept' verdict in chain 'ssh'.

Is this desired behaviour or is there a bug in chain traversal?

I tested using current nf-next tree, but comparing it's history to that
of current net doesn't show any change which might be related.

Help?

Cheers, Phil