aboutsummaryrefslogtreecommitdiffstats
path: root/net/xfrm
diff options
context:
space:
mode:
authorHerbert Xu <herbert@gondor.apana.org.au>2006-02-13 16:01:27 -0800
committerDavid S. Miller <davem@davemloft.net>2006-02-13 16:01:27 -0800
commit00de651d14baabc5c1d2f32c49d9a984d8891c8e (patch)
treedee86291586baf00e9c34dd8f4545088a36877ef /net/xfrm
parent6d3e85ecf22a5e3610df47b9c3fb2fc32cfd35bf (diff)
downloadkernel_samsung_crespo-00de651d14baabc5c1d2f32c49d9a984d8891c8e.zip
kernel_samsung_crespo-00de651d14baabc5c1d2f32c49d9a984d8891c8e.tar.gz
kernel_samsung_crespo-00de651d14baabc5c1d2f32c49d9a984d8891c8e.tar.bz2
[IPSEC]: Fix strange IPsec freeze.
Problem discovered and initial patch by Olaf Kirch: there's a problem with IPsec that has been bugging some of our users for the last couple of kernel revs. Every now and then, IPsec will freeze the machine completely. This is with openswan user land, and with kernels up to and including 2.6.16-rc2. I managed to debug this a little, and what happens is that we end up looping in xfrm_lookup, and never get out. With a bit of debug printks added, I can this happening: ip_route_output_flow calls xfrm_lookup xfrm_find_bundle returns NULL (apparently we're in the middle of negotiating a new SA or something) We therefore call xfrm_tmpl_resolve. This returns EAGAIN We go to sleep, waiting for a policy update. Then we loop back to the top Apparently, the dst_orig that was passed into xfrm_lookup has been dropped from the routing table (obsolete=2) This leads to the endless loop, because we now create a new bundle, check the new bundle and find it's stale (stale_bundle -> xfrm_bundle_ok -> dst_check() return 0) People have been testing with the patch below, which seems to fix the problem partially. They still see connection hangs however (things only clear up when they start a new ping or new ssh). So the patch is obvsiouly not sufficient, and something else seems to go wrong. I'm grateful for any hints you may have... I suggest that we simply bail out always. If the dst decides to die on us later on, the packet will be dropped anyway. So there is no great urgency to retry here. Once we have the proper resolution queueing, we can then do the retry again. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Olaf Kirch <okir@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/xfrm')
-rw-r--r--net/xfrm/xfrm_policy.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index dbf4620..98ec53b 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -889,7 +889,9 @@ restart:
xfrm_pol_put(policy);
if (dst)
dst_free(dst);
- goto restart;
+
+ err = -EHOSTUNREACH;
+ goto error;
}
dst->next = policy->bundles;
policy->bundles = dst;