summaryrefslogtreecommitdiff
path: root/fs/xfs/xfs_exchrange.c
diff options
context:
space:
mode:
authorPhil Sutter <phil@nwl.cc>2024-12-17 22:56:55 +0300
committerPablo Neira Ayuso <pablo@netfilter.org>2024-12-19 02:28:47 +0300
commit70b6f46a4ed8bd56c85ffff22df91e20e8c85e33 (patch)
tree0acd104e4fda7bb249e5fd50ace81a697e80cd5e /fs/xfs/xfs_exchrange.c
parentcf2c97423a4f89c8b798294d3f34ecfe7e7035c3 (diff)
downloadlinux-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