1. 14 Feb, 2006 2 commits
    • David S. Miller's avatar
      [NET]: Revert skb_copy_datagram_iovec() recursion elimination. · b4d9eda0
      David S. Miller authored
      Revert the following changeset:
      
      bc8dfcb9
      
      Recursive SKB frag lists are really possible and disallowing
      them breaks things.
      
      Noticed by: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4d9eda0
    • Herbert Xu's avatar
      [IPSEC]: Fix strange IPsec freeze. · 00de651d
      Herbert Xu authored
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarOlaf Kirch <okir@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00de651d
  2. 13 Feb, 2006 23 commits
  3. 12 Feb, 2006 15 commits