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 --- iptables/nft.c | 3 +++ .../testcases/ipt-restore/0003-restore-ordering_0 | 18 +++++++++++++----- 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/iptables/nft.c b/iptables/nft.c index a2c43e83..0249cbbe 100644 --- a/iptables/nft.c +++ b/iptables/nft.c @@ -2199,6 +2199,9 @@ static int __nft_rule_del(struct nft_handle *h, struct nftnl_rule *r) nftnl_rule_list_del(r); + if (!nftnl_rule_get_u64(r, NFTNL_RULE_HANDLE)) + nftnl_rule_set_u32(r, NFTNL_RULE_ID, ++h->rule_id); + obj = batch_rule_add(h, NFT_COMPAT_RULE_DELETE, r); if (!obj) { nftnl_rule_free(r); 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 <