Skip to contentSkip to conversation

netfilter: ipset: Fix sleeping memory allocation in atomic context

PATCH Applied Nikolay Borisov 3 participants 3 messages Oct 16, 2015 – Oct 17, 2015

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH v3 1/1 netfilter: ipset: Fix sleeping memory allocation in atomic context

Commit 00590fdd5be0 introduced RCU locking in list type and in doing so introduced a memory allocation in list_set_add, which is done in an atomic context, due to the fact that ipset rcu list modifications are serialised with a spin lock. The reason why we can't use a mutex is that in addition to modifying the list with ipset commands, it's also being modified when a particular ipset rule timeout expires aka garbage collection. This gc is triggered from set_cleanup_entries, which in turn is invoked from a timer thus requiring the lock to be bh-safe.

Concretely the following call chain can lead to "sleeping function called in atomic context" splat:
call_ad -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL). And since GFP_KERNEL allows initiating direct reclaim thus potentially sleeping in the allocation path.

To fix the issue change the allocation type to GFP_ATOMIC, to correctly reflect that it is occuring in an atomic context.

Fixes 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in list type")

---

Changes since v2:
* Massaged the changelog to reflect discussion
on the mailing list

Changes since v1:
* Added acked-by
* Fixed patch header

 net/netfilter/ipset/ip_set_list_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/ipset/ip_set_list_set.c +1 -1
index a1fe537..5a30ce6 100644
@@ -297,7 +297,7 @@ list_set_uadd(struct ip_set *set, void *value, const struct ip_set_ext *ext,
 	      ip_set_timeout_expired(ext_timeout(n, set))))
 		n =  NULL;
 
-	e = kzalloc(set->dsize, GFP_KERNEL);
+	e = kzalloc(set->dsize, GFP_ATOMIC);
 	if (!e)
 		return -ENOMEM;
 	e->id = d->id;
Signature · 1 line
2.5.0
#1 lore raw
Quoted 29 lines · Nikolay Borisov

Commit 00590fdd5be0 introduced RCU locking in list type and in doing so introduced a memory allocation in list_set_add, which is done in an atomic context, due to the fact that ipset rcu list modifications are serialised with a spin lock. The reason why we can't use a mutex is that in addition to modifying the list with ipset commands, it's also being modified when a particular ipset rule timeout expires aka garbage collection. This gc is triggered from set_cleanup_entries, which in turn is invoked from a timer thus requiring the lock to be bh-safe.

Concretely the following call chain can lead to "sleeping function called in atomic context" splat:
call_ad -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL). And since GFP_KERNEL allows initiating direct reclaim thus potentially sleeping in the allocation path.

To fix the issue change the allocation type to GFP_ATOMIC, to correctly reflect that it is occuring in an atomic context.

Fixes 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in list type")

---

Changes since v2:
* Massaged the changelog to reflect discussion
on the mailing list

Quoted 8 lines

Changes since v1:
* Added acked-by
* Fixed patch header

 net/netfilter/ipset/ip_set_list_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

The patch is applied in the ipset package tree. Thanks!

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences

          H-1525 Budapest 114, POB. 49, Hungary
maintainer Applied
#2 lore raw
Quoted 1 line · Jozsef Kadlecsik

The patch is applied in the ipset package tree. Thanks!

Applied to the nf tree, thanks.