This patch ensures that the hard state/policy expire notifications are only sent when the state/policy is successfully removed from their respective tables. As it is, it's possible for a state/polic
This is nice since it seems to go on top of the patch i posted. I didnt get an ACK from Dave - so i assumed that patch is not on his tree yet. Which tree are you using? Small comment below: If the p
Hi Jamal: The Linus tree plus your patch. You're right. The other callers of xfrm_policy_kill needs to check it too. I'll fix this up. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Her
Actually, my code was right :) xfrm_policy_kill can only be called by the one who removed the policy from the linked list. Therefore it can never fail. If this logic is wrong we will be getting fat w
The warning will kick in but it may be as rare as the issue of a delete and expire happening on the same policy that your patch was supposed to stop ;-> cheers, jamal
What I am saying is that this is impossible. If it really bothers you we can turn the WARN_ON into a BUG. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@x
We started this discussion by asserting that an expire may be issued on a policy (or state) despite a delete event notification already having happened. Thats what we were/are trying to stop, no? Wh
Hi Jamal: Yes. xfrm_policy_delete returns 0 if and only if the policy was removed from xfrm_policy_list. A user-initiated delete policy action can only succeed if the policy was removed from xfrm_pol
Ok, what you are saying is sensible, but: does this mean there was never an issue then there was never a possibility of delete and expire intefering with each other then? cheers, jamal
The problem before was that the timer didn't check the return value of xfrm_policy_delete (in fact the latter didn't return anything). xfrm_policy_delete tself always checked whether it succeeded in
Hi: This patch ensures that the hard state/policy expire notifications are only sent when the state/policy is successfully removed from their respective tables. As it is, it's possible for a state/po
Herbert, This is nice since it seems to go on top of the patch i posted. I didnt get an ACK from Dave - so i assumed that patch is not on his tree yet. Which tree are you using? Small comment below:
Hi Jamal: The Linus tree plus your patch. You're right. The other callers of xfrm_policy_kill needs to check it too. I'll fix this up. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Her
Actually, my code was right :) xfrm_policy_kill can only be called by the one who removed the policy from the linked list. Therefore it can never fail. If this logic is wrong we will be getting fat w
The warning will kick in but it may be as rare as the issue of a delete and expire happening on the same policy that your patch was supposed to stop ;-> cheers, jamal
What I am saying is that this is impossible. If it really bothers you we can turn the WARN_ON into a BUG. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@x
Herbert, We started this discussion by asserting that an expire may be issued on a policy (or state) despite a delete event notification already having happened. Thats what we were/are trying to stop
Hi Jamal: Yes. xfrm_policy_delete returns 0 if and only if the policy was removed from xfrm_policy_list. A user-initiated delete policy action can only succeed if the policy was removed from xfrm_pol
Herbert, Ok, what you are saying is sensible, but: does this mean there was never an issue then there was never a possibility of delete and expire intefering with each other then? cheers, jamal
The problem before was that the timer didn't check the return value of xfrm_policy_delete (in fact the latter didn't return anything). xfrm_policy_delete tself always checked whether it succeeded in