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 point expected timer when the first > packet arrives, then we do an immediate update of type > XFRM_REPLAY_TIMEOUT else we keep receiving packets and wait until the > right time.
Ok, this certainly fixes the corner case. About the wrap-around: as Herbert wrote, in any sane setup there won't be a problem. time_after_eq() returns correct results as long as the difference between the arguments is less than MAX_LONG, on 32 bit architectures with HZ=1000 this means roughly 24 days. Let's assume repla_maxage is negligible compared to jiffies. So in case we don't have any traffic for about 24 days then we'll miss the XFRM_REPLAY_TIMEOUT notification. Not a very realistic scenario IMHO. But I still perfer the flag. With this timestamp thing you introduce a delay of replay_maxage jiffies. Say the timer fires, but there was no traffic so no notification is sent. With the timestamp you won't generate an event for another replay_maxage even if there were some packets sent (but not reaching the seqno threshold). With only the flag we'll have a notification right at the first packet. I think this might allow slightly more accurate tracking of sequence numbers. > I havent tested this so there maybe holes, it compiles though. I would > like to test it first (probably at end of day) and then submit; so > please review and provide comments which i can incorporate before i > punt to Dave. 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() to drop the reference we acquired when starting the timer. -- Regards, Krisztian Kovacs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
