1. 07 12月, 2006 3 次提交
  2. 03 12月, 2006 1 次提交
  3. 22 11月, 2006 1 次提交
  4. 25 10月, 2006 1 次提交
  5. 16 10月, 2006 1 次提交
  6. 04 10月, 2006 1 次提交
  7. 29 9月, 2006 6 次提交
  8. 23 9月, 2006 22 次提交
  9. 22 7月, 2006 1 次提交
  10. 30 6月, 2006 1 次提交
  11. 18 6月, 2006 2 次提交
    • H
      [IPSEC] xfrm: Abstract out encapsulation modes · b59f45d0
      Herbert Xu 提交于
      This patch adds the structure xfrm_mode.  It is meant to represent
      the operations carried out by transport/tunnel modes.
      
      By doing this we allow additional encapsulation modes to be added
      without clogging up the xfrm_input/xfrm_output paths.
      
      Candidate modes include 4-to-6 tunnel mode, 6-to-4 tunnel mode, and
      BEET modes.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b59f45d0
    • H
      [IPSEC] xfrm: Undo afinfo lock proliferation · 546be240
      Herbert Xu 提交于
      The number of locks used to manage afinfo structures can easily be reduced
      down to one each for policy and state respectively.  This is based on the
      observation that the write locks are only held by module insertion/removal
      which are very rare events so there is no need to further differentiate
      between the insertion of modules like ipv6 versus esp6.
      
      The removal of the read locks in xfrm4_policy.c/xfrm6_policy.c might look
      suspicious at first.  However, after you realise that nobody ever takes
      the corresponding write lock you'll feel better :)
      
      As far as I can gather it's an attempt to guard against the removal of
      the corresponding modules.  Since neither module can be unloaded at all
      we can leave it to whoever fixes up IPv6 unloading :)
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      546be240