diff options
author | Florian Westphal <fw@strlen.de> | 2020-08-09 20:28:01 +0200 |
---|---|---|
committer | Pablo Neira Ayuso <pablo@netfilter.org> | 2020-08-10 13:03:36 +0200 |
commit | 2f941622fd88328ca75806c45c9e9709286a0609 (patch) | |
tree | 22713ff90ee7424536005f969f46618684629efd /kernel/cred.c | |
parent | b428336676dbca363262cc134b6218205df4f530 (diff) | |
download | linux-stable-2f941622fd88328ca75806c45c9e9709286a0609.tar.gz linux-stable-2f941622fd88328ca75806c45c9e9709286a0609.tar.bz2 linux-stable-2f941622fd88328ca75806c45c9e9709286a0609.zip |
netfilter: nft_compat: remove flush counter optimization
WARNING: CPU: 1 PID: 16059 at lib/refcount.c:31 refcount_warn_saturate+0xdf/0xf
[..]
__nft_mt_tg_destroy+0x42/0x50 [nft_compat]
nft_target_destroy+0x63/0x80 [nft_compat]
nf_tables_expr_destroy+0x1b/0x30 [nf_tables]
nf_tables_rule_destroy+0x3a/0x70 [nf_tables]
nf_tables_exit_net+0x186/0x3d0 [nf_tables]
Happens when a compat expr is destoyed from abort path.
There is no functional impact; after this work queue is flushed
unconditionally if its pending.
This removes the waitcount optimization. Test of repeated
iptables-restore of a ~60k kubernetes ruleset doesn't indicate
a slowdown. In case the counter is needed after all for some workloads
we can revert this and increment the refcount for the
!= NFT_PREPARE_TRANS case to avoid the increment/decrement imbalance.
While at it, also flush for match case, this was an oversight
in the original patch.
Fixes: ffe8923f109b7e ("netfilter: nft_compat: make sure xtables destructors have run")
Reported-by: kernel test robot <rong.a.chen@intel.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'kernel/cred.c')
0 files changed, 0 insertions, 0 deletions