Hi,
On Tuesday 11 April 2006 05.02, jamal wrote:
> Ok, if both you can provide feedback on the attached patch (untested but
> compiles) I will make any necessary changes, test and push this +
> documentation to Dave.
Looks ok, although I only had a quick look at it.
--
Regards,
Krisztia
Hi Jamal:
On Mon, Apr 10, 2006 at 11:02:06PM -0400, jamal wrote:
>
> Ok, if both you can provide feedback on the attached patch (untested but
> compiles) I will make any necessary changes, test and push this +
> documentation to Dave.
Looks good to me.
> diff --git a/net/xfrm/xfrm_state.c b/net
On Tue, 2006-11-04 at 00:34 +0200, KOVACS Krisztian wrote:
[..]
> But I still perfer the flag.
Ok, so consensus is to use a flag.
> Another thing still present is the possible xfrm_state leak. I think we
> need to call xfrm_state_put() as the last statement of
> xfrm_replay_timer_handler()
Hi,
On Friday 07 April 2006 15:15, jamal wrote:
> Ok, I built on Herbert's suggestion and tried to be a little
> clever/accurate. Instead of a flag i introduce a variable that stores
> the jiffy point when the timer is killed. If we fall anywhere to the
> right or at exact point of the next poi
On Sat, 2006-08-04 at 00:14 +1000, Herbert Xu wrote:
> This looks good except that I think the flag beats jiffies since the
> latter can wrap around. Of course on any sane setup the SA should've
> expired by then but it pays to be safe.
>
Ok, Lets hear Krisztian's view for a tie breaker. Whiche
Hi Jamal:
On Fri, Apr 07, 2006 at 09:15:41AM -0400, jamal wrote:
>
> Ok, I built on Herbert's suggestion and tried to be a little
> clever/accurate. Instead of a flag i introduce a variable that stores
> the jiffy point when the timer is killed. If we fall anywhere to the
> right or at exact poin
On Thu, 2006-06-04 at 22:13 +0200, KOVACS Krisztian wrote:
> Hi,
>
> On Thursday 06 April 2006 17:18, jamal wrote:
> > On Fri, 2006-07-04 at 00:30 +1000, Herbert Xu wrote:
> > > If so I see what you mean but I think a better solution is to just
> > > set a flag when the XFRM_REPLAY_TIMEOUT fires
Hi,
On Thursday 06 April 2006 17:18, jamal wrote:
> On Fri, 2006-07-04 at 00:30 +1000, Herbert Xu wrote:
> > If so I see what you mean but I think a better solution is to just
> > set a flag when the XFRM_REPLAY_TIMEOUT fires and nothing has
> > changed. Then when you get XFRM_REPLAY_UPDATE you
On Thu, 2006-06-04 at 11:18 -0400, jamal wrote:
> After a little testing (i missed the scenario where a user subscribes
> and then leaves and then resubscribes; in such a case, the timer never
> gets restarted) i have updated the patch to do it the brute force way.
> What you propose is more optim
On Fri, 2006-07-04 at 00:30 +1000, Herbert Xu wrote:
> If so I see what you mean but I think a better solution is to just
> set a flag when the XFRM_REPLAY_TIMEOUT fires and nothing has changed.
> Then when you get XFRM_REPLAY_UPDATE you can notify unconditionally if
> this flag is set.
>
> The f
Hi Jamal:
On Thu, Apr 06, 2006 at 09:03:07AM -0400, jamal wrote:
>
> Both Krisztian and myself independently bumped into this problem.
> Summary is: it is problematic to do reasonably timed failovers without
> that timer that was initially in the original patch.
Do you mean a case where you have
Herbert,
Both Krisztian and myself independently bumped into this problem.
Summary is: it is problematic to do reasonably timed failovers without
that timer that was initially in the original patch.
So i am attaching a patch against Linus' tree.
Dave, If Herbert acks, please apply this to Linus
12 matches
Mail list logo
