diff options
author | Phil Sutter <phil@nwl.cc> | 2024-12-17 22:56:55 +0300 |
---|---|---|
committer | Pablo Neira Ayuso <pablo@netfilter.org> | 2024-12-19 02:28:47 +0300 |
commit | 70b6f46a4ed8bd56c85ffff22df91e20e8c85e33 (patch) | |
tree | 0acd104e4fda7bb249e5fd50ace81a697e80cd5e /fs/xfs/xfs_exchrange.c | |
parent | cf2c97423a4f89c8b798294d3f34ecfe7e7035c3 (diff) | |
download | linux-70b6f46a4ed8bd56c85ffff22df91e20e8c85e33.tar.xz |
netfilter: ipset: Fix for recursive locking warning
With CONFIG_PROVE_LOCKING, when creating a set of type bitmap:ip, adding
it to a set of type list:set and populating it from iptables SET target
triggers a kernel warning:
| WARNING: possible recursive locking detected
| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted
| --------------------------------------------
| ping/4018 is trying to acquire lock:
| ffff8881094a6848 (&set->lock){+.-.}-{2:2}, at: ip_set_add+0x28c/0x360 [ip_set]
|
| but task is already holding lock:
| ffff88811034c048 (&set->lock){+.-.}-{2:2}, at: ip_set_add+0x28c/0x360 [ip_set]
This is a false alarm: ipset does not allow nested list:set type, so the
loop in list_set_kadd() can never encounter the outer set itself. No
other set type supports embedded sets, so this is the only case to
consider.
To avoid the false report, create a distinct lock class for list:set
type ipset locks.
Fixes: f830837f0eed ("netfilter: ipset: list:set set type support")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'fs/xfs/xfs_exchrange.c')
0 files changed, 0 insertions, 0 deletions