1. 29 1月, 2008 32 次提交
  2. 09 1月, 2008 1 次提交
  3. 04 1月, 2008 1 次提交
  4. 20 12月, 2007 1 次提交
  5. 15 12月, 2007 1 次提交
  6. 11 12月, 2007 1 次提交
  7. 29 11月, 2007 1 次提交
    • H
      [IPSEC]: Fix uninitialised dst warning in __xfrm_lookup · 5e5234ff
      Herbert Xu 提交于
      Andrew Morton reported that __xfrm_lookup generates this warning:
      
      net/xfrm/xfrm_policy.c: In function '__xfrm_lookup':
      net/xfrm/xfrm_policy.c:1449: warning: 'dst' may be used uninitialized in this function
      
      This is because if policy->action is of an unexpected value then dst will
      not be initialised.  Of course, in practice this should never happen since
      the input layer xfrm_user/af_key will filter out all illegal values.  But
      the compiler doesn't know that of course.
      
      So this patch fixes this by taking the conservative approach and treat all
      unknown actions the same as a blocking action.
      
      Thanks to Andrew for finding this and providing an initial fix.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5e5234ff
  8. 27 11月, 2007 1 次提交
  9. 26 11月, 2007 1 次提交
    • H
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      Herbert Xu 提交于
      The change 050f009e
      
      	[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: NHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d