Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 2月, 2010 1 次提交
  3. 20 2月, 2010 1 次提交
  5. 18 2月, 2010 1 次提交
    • D
      xfrm: Revert false event eliding commits. · 069c474e
      由 David S. Miller 提交于 
      As reported by Alexey Dobriyan:

--------------------
setkey now takes several seconds to run this simple script
and it spits "recv: Resource temporarily unavailable" messages.

#!/usr/sbin/setkey -f
flush;
spdflush;

add A B ipcomp 44 -m tunnel -C deflate;
add B A ipcomp 45 -m tunnel -C deflate;

spdadd A B any -P in ipsec
        ipcomp/tunnel/192.168.1.2-192.168.1.3/use;
spdadd B A any -P out ipsec
        ipcomp/tunnel/192.168.1.3-192.168.1.2/use;
--------------------

Obviously applications want the events even when the table
is empty.  So we cannot make this behavioral change.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      069c474e
  7. 17 2月, 2010 2 次提交
  9. 16 2月, 2010 1 次提交
    • 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
  11. 24 1月, 2010 1 次提交
  13. 26 11月, 2009 1 次提交
  15. 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
  17. 30 6月, 2009 1 次提交
  19. 27 4月, 2009 1 次提交
  21. 27 3月, 2009 1 次提交
  23. 14 3月, 2009 1 次提交
  25. 04 12月, 2008 1 次提交
  27. 26 11月, 2008 23 次提交
  29. 31 10月, 2008 1 次提交
  31. 30 10月, 2008 1 次提交
  33. 29 10月, 2008 1 次提交