1. 16 2月, 2010 2 次提交
    • J
      xfrm: Flushing empty SPD generates false events · 0dca3a84
      jamal 提交于
      Observed similar behavior on SPD as previouly seen on SAD flushing..
      This fixes it.
      
      cheers,
      jamal
      commit 428b20432dc31bc2e01a94cd451cf5a2c00d2bf4
      Author: Jamal Hadi Salim <hadi@cyberus.ca>
      Date:   Thu Feb 11 05:49:38 2010 -0500
      
          xfrm: Flushing empty SPD generates false events
      
          To see the effect make sure you have an empty SPD.
          On window1 "ip xfrm mon" and on window2 issue "ip xfrm policy flush"
          You get prompt back in window1 and you see the flush event on window2.
          With this fix, you still get prompt on window1 but no event on window2.
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0dca3a84
    • J
      xfrm: Flushing empty SAD generates false events · 19f4c713
      jamal 提交于
      To see the effect make sure you have an empty SAD.
      -On window1 "ip xfrm mon"
      -on window2 issue "ip xfrm state flush"
      You get prompt back in window1
      and you see the flush event on window2.
      With this fix, you still get prompt on window1 but no
      event on window2.
      
      I was tempted to return -ESRCH on window1 (which would
      show "RTNETLINK answers: No such process") but didnt want
      to change current behavior.
      
      cheers,
      jamal
      commit 5f3dd4a772326166e1bcf54acc2391df00dc7ab5
      Author: Jamal Hadi Salim <hadi@cyberus.ca>
      Date:   Thu Feb 11 04:41:36 2010 -0500
      
          xfrm: Flushing empty SAD generates false events
      
          To see the effect make sure you have an empty SAD.
          On window1 "ip xfrm mon" and on window2 issue "ip xfrm state flush"
          You get prompt back in window1 and you see the flush event on window2.
          With this fix, you still get prompt on window1 but no event on window2.
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19f4c713
  2. 13 2月, 2010 1 次提交
  3. 25 1月, 2010 1 次提交
  4. 24 1月, 2010 1 次提交
  5. 23 1月, 2010 1 次提交
  6. 18 1月, 2010 1 次提交
  7. 27 12月, 2009 1 次提交
  8. 04 12月, 2009 1 次提交
  9. 02 12月, 2009 1 次提交
  10. 26 11月, 2009 2 次提交
  11. 12 11月, 2009 1 次提交
    • E
      sysctl net: Remove unused binary sysctl code · f8572d8f
      Eric W. Biederman 提交于
      Now that sys_sysctl is a compatiblity wrapper around /proc/sys
      all sysctl strategy routines, and all ctl_name and strategy
      entries in the sysctl tables are unused, and can be
      revmoed.
      
      In addition neigh_sysctl_register has been modified to no longer
      take a strategy argument and it's callers have been modified not
      to pass one.
      
      Cc: "David Miller" <davem@davemloft.net>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      f8572d8f
  12. 09 11月, 2009 1 次提交
    • Y
      xfrm: SAD entries do not expire correctly after suspend-resume · 9e0d57fd
      Yury Polyanskiy 提交于
        This fixes the following bug in the current implementation of
      net/xfrm: SAD entries timeouts do not count the time spent by the machine 
      in the suspended state. This leads to the connectivity problems because 
      after resuming local machine thinks that the SAD entry is still valid, while 
      it has already been expired on the remote server.
      
        The cause of this is very simple: the timeouts in the net/xfrm are bound to 
      the old mod_timer() timers. This patch reassigns them to the
      CLOCK_REALTIME hrtimer.
      
        I have been using this version of the patch for a few months on my
      machines without any problems. Also run a few stress tests w/o any
      issues.
      
        This version of the patch uses tasklet_hrtimer by Peter Zijlstra
      (commit 9ba5f0).
      
        This patch is against 2.6.31.4. Please CC me.
      Signed-off-by: NYury Polyanskiy <polyanskiy@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e0d57fd
  13. 19 10月, 2009 1 次提交
  14. 02 9月, 2009 1 次提交
  15. 10 8月, 2009 1 次提交
  16. 30 6月, 2009 1 次提交
  17. 25 6月, 2009 1 次提交
  18. 09 6月, 2009 1 次提交
  19. 03 6月, 2009 1 次提交
  20. 27 4月, 2009 1 次提交
  21. 27 3月, 2009 1 次提交
  22. 14 3月, 2009 1 次提交
  23. 21 1月, 2009 1 次提交
  24. 15 1月, 2009 1 次提交
  25. 11 1月, 2009 1 次提交
  26. 30 12月, 2008 1 次提交
  27. 19 12月, 2008 1 次提交
  28. 15 12月, 2008 1 次提交
  29. 05 12月, 2008 1 次提交
  30. 04 12月, 2008 1 次提交
  31. 03 12月, 2008 2 次提交
    • W
      xfrm: Cleanup for unlink SPD entry · 29fa0b30
      Wei Yongjun 提交于
      Used __xfrm_policy_unlink() to instead of the dup codes when unlink
      SPD entry.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29fa0b30
    • W
      xfrm: Fix kernel panic when flush and dump SPD entries · d5654efd
      Wei Yongjun 提交于
      After flush the SPD entries, dump the SPD entries will cause kernel painc.
      
      Used the following commands to reproduct:
      
      - echo 'spdflush;' | setkey -c
      - echo 'spdadd 3ffe:501:ffff:ff01::/64 3ffe:501:ffff:ff04::/64  any -P out ipsec \
        ah/tunnel/3ffe:501:ffff:ff00:200:ff:fe00:b0b0-3ffe:501:ffff:ff02:200:ff:fe00:a1a1/require;\
        spddump;' | setkey -c
      - echo 'spdflush; spddump;' | setkey -c
      - echo 'spdadd 3ffe:501:ffff:ff01::/64 3ffe:501:ffff:ff04::/64  any -P out ipsec \
        ah/tunnel/3ffe:501:ffff:ff00:200:ff:fe00:b0b0-3ffe:501:ffff:ff02:200:ff:fe00:a1a1/require;\
        spddump;' | setkey -c
      
      This is because when flush the SPD entries, the SPD entry is not remove
      from the list.
      
      This patch fix the problem by remove the SPD entry from the list.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5654efd
  32. 26 11月, 2008 6 次提交