]> git.ipfire.org Git - thirdparty/ipset.git/commit
netfilter: ipset: Fix for recursive locking warning
authorPhil Sutter <phil@nwl.cc>
Tue, 17 Dec 2024 19:56:55 +0000 (20:56 +0100)
committerJozsef Kadlecsik <kadlec@netfilter.org>
Thu, 19 Dec 2024 09:47:06 +0000 (10:47 +0100)
commitcee6ea289ad448aa8d8e3fb4aa64cf6cb6c3aea4
tree0caeddceb35e301454e1cf07e02de6338e0087a2
parentdeccb507c701ca9c82eeab5a588b55d9d465e125
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.

Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
kernel/net/netfilter/ipset/ip_set_list_set.c