iptables-restore: free the table lock when skipping a table

Currently, when running `iptables-restore --table=X`, where `X` is not the first
table in the rules dump, the restore will fail when parsing the second table:

- a lock is acquird when parsing the first table name
- the table name does not match the parameter to `--table` so processing
  continues until the next table
- when processing the next table a lock is acquired, which fails because a lock
  is already held

Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

This will release the lock as soon as it's decided the current table won't be
used.

Signed-off-by: Joel Goguen <contact+netfilter@jgoguen.ca>
Signed-off-by: Florian Westphal <fw@strlen.de>

1 files changed, 30 insertions, 0 deletions

diff --git a/iptables/tests/shell/testcases/ipt-restore/dumps/ip6tables.dump b/iptables/tests/shell/testcases/ipt-restore/dumps/ip6tables.dump
new file mode 100644
index 00000000..4ac4f882
--- /dev/null
+++ b/iptables/tests/shell/testcases/ipt-restore/dumps/ip6tables.dump
@@ -0,0 +1,30 @@
+*nat
+:PREROUTING ACCEPT [0:0]
+:INPUT ACCEPT [0:0]
+:OUTPUT ACCEPT [8:656]
+:POSTROUTING ACCEPT [8:656]
+COMMIT
+
+*mangle
+:PREROUTING ACCEPT [794:190738]
+:INPUT ACCEPT [794:190738]
+:FORWARD ACCEPT [0:0]
+:OUTPUT ACCEPT [991:170303]
+:POSTROUTING ACCEPT [991:170303]
+COMMIT
+
+*raw
+:PREROUTING ACCEPT [794:190738]
+:OUTPUT ACCEPT [991:170303]
+COMMIT
+
+*filter
+:INPUT DROP [0:0]
+:FORWARD DROP [0:0]
+:OUTPUT ACCEPT [991:170303]
+-A INPUT -i lo -j ACCEPT
+-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
+-A INPUT -p ipv6-icmp -j ACCEPT
+-A OUTPUT -p tcp -m tcp --dport 137 -j REJECT --reject-with icmp6-port-unreachable
+-A OUTPUT -p udp -m udp --dport 137 -j REJECT --reject-with icmp6-port-unreachable
+COMMIT