Thread (26 messages) 26 messages, 7 authors, 2014-03-10

RE: [PATCH 1/2] net: af_key: fix sleeping under rcu

From: David Laight <hidden>
Date: 2014-03-04 12:47:15

From: Nikolay Aleksandrov
There's a kmalloc with GFP_KERNEL in a helper
(pfkey_sadb2xfrm_user_sec_ctx) used in pfkey_compile_policy which is
called under rcu_read_lock. Adjust pfkey_sadb2xfrm_user_sec_ctx to have
a gfp argument and adjust the users.
...
quoted hunk ↗ jump to hunk
@@ -3239,7 +3240,7 @@ static struct xfrm_policy *pfkey_compile_policy(struct sock *sk, int opt,
 		}
 		if ((*dir = verify_sec_ctx_len(p)))
 			goto out;
-		uctx = pfkey_sadb2xfrm_user_sec_ctx(sec_ctx);
+		uctx = pfkey_sadb2xfrm_user_sec_ctx(sec_ctx, GFP_ATOMIC);
 		*dir = security_xfrm_policy_alloc(&xp->security, uctx);
 		kfree(uctx);
This looks like the only one that isn't passed GFP_KERNEL.
It looks as though it is missing the check for the allocation failing
(there might be a check inside security_xfrm_policy_alloc()).

In any case it looks as though this ought to be codeable without
the allocation of 'uctx' - since it is freed a line later.

I'd have thought that some of these paths should be allocating
the memory outside the rcu (where they can sleep) and then
possibly freeing the unused data later.

Returning ENOMEM doesn't really seem helpful.

	David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help