From 760b35b46e4cc3aabe9214027959266df23a0122 Mon Sep 17 00:00:00 2001 From: Phil Sutter Date: Tue, 3 Sep 2019 18:10:55 +0200 Subject: nft: Fix for add and delete of same rule in single batch Another corner-case found when extending restore ordering test: If a delete command in a dump referenced a rule added earlier within the same dump, kernel would reject the resulting NFT_MSG_DELRULE command. Catch this by assigning the rule to delete a RULE_ID value if it doesn't have a handle yet. Since __nft_rule_del() does not duplicate the nftnl_rule object when creating the NFT_COMPAT_RULE_DELETE command, this RULE_ID value is added to both NEWRULE and DELRULE commands - exactly what is needed to establish the reference. Signed-off-by: Phil Sutter Acked-by: Florian Westphal --- .../testcases/ipt-restore/0003-restore-ordering_0 | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) (limited to 'iptables/tests/shell/testcases/ipt-restore/0003-restore-ordering_0') diff --git a/iptables/tests/shell/testcases/ipt-restore/0003-restore-ordering_0 b/iptables/tests/shell/testcases/ipt-restore/0003-restore-ordering_0 index 51f2422e..3f1d229e 100755 --- a/iptables/tests/shell/testcases/ipt-restore/0003-restore-ordering_0 +++ b/iptables/tests/shell/testcases/ipt-restore/0003-restore-ordering_0 @@ -14,7 +14,7 @@ ipt_show() { $XT_MULTI iptables-restore <