Searched hist:"050 f009e16f908932070313c1745d09dc69fd62b" (Results 1 – 2 of 2) sorted by relevance
| /linux/net/key/ |
| H A D | af_key.c | diff 8053fc3de720e1027d690f892ff7d7c1737fdd9d Mon Nov 26 12:07:34 CET 2007 Herbert Xu <herbert@gondor.apana.org.au> [IPSEC]: Temporarily remove locks around copying of non-atomic fields
The change 050f009e16f908932070313c1745d09dc69fd62b
[IPSEC]: Lock state when copying non-atomic fields to user-space
caused a regression.
Ingo Molnar reports that it causes a potential dead-lock found by the
lock validator as it tries to take x->lock within xfrm_state_lock while
numerous other sites take the locks in opposite order.
For 2.6.24, the best fix is to simply remove the added locks as that puts
us back in the same state as we've been in for years. For later kernels
a proper fix would be to reverse the locking order for every xfrm state
user such that if x->lock is taken together with xfrm_state_lock then
it is to be taken within it.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff 050f009e16f908932070313c1745d09dc69fd62b Tue Oct 09 22:31:47 CEST 2007 Herbert Xu <herbert@gondor.apana.org.au> [IPSEC]: Lock state when copying non-atomic fields to user-space
This patch adds locking so that when we're copying non-atomic fields such as
life-time or coaddr to user-space we don't get a partial result.
For af_key I've changed every instance of pfkey_xfrm_state2msg apart from
expiration notification to include the keys and life-times. This is in-line
with XFRM behaviour.
The actual cases affected are:
* pfkey_getspi: No change as we don't have any keys to copy.
* key_notify_sa:
+ ADD/UPD: This wouldn't work otherwise.
+ DEL: It can't hurt.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| /linux/net/xfrm/ |
| H A D | xfrm_user.c | diff 8053fc3de720e1027d690f892ff7d7c1737fdd9d Mon Nov 26 12:07:34 CET 2007 Herbert Xu <herbert@gondor.apana.org.au> [IPSEC]: Temporarily remove locks around copying of non-atomic fields
The change 050f009e16f908932070313c1745d09dc69fd62b
[IPSEC]: Lock state when copying non-atomic fields to user-space
caused a regression.
Ingo Molnar reports that it causes a potential dead-lock found by the
lock validator as it tries to take x->lock within xfrm_state_lock while
numerous other sites take the locks in opposite order.
For 2.6.24, the best fix is to simply remove the added locks as that puts
us back in the same state as we've been in for years. For later kernels
a proper fix would be to reverse the locking order for every xfrm state
user such that if x->lock is taken together with xfrm_state_lock then
it is to be taken within it.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff 050f009e16f908932070313c1745d09dc69fd62b Tue Oct 09 22:31:47 CEST 2007 Herbert Xu <herbert@gondor.apana.org.au> [IPSEC]: Lock state when copying non-atomic fields to user-space
This patch adds locking so that when we're copying non-atomic fields such as
life-time or coaddr to user-space we don't get a partial result.
For af_key I've changed every instance of pfkey_xfrm_state2msg apart from
expiration notification to include the keys and life-times. This is in-line
with XFRM behaviour.
The actual cases affected are:
* pfkey_getspi: No change as we don't have any keys to copy.
* key_notify_sa:
+ ADD/UPD: This wouldn't work otherwise.
+ DEL: It can't hurt.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|