Messages in this thread | | | Date | Fri, 13 Sep 2013 10:46:42 +0800 | From | Fan Du <> | Subject | Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called |
| |
Hi Dave/Thomas
On 2013年09月13日 01:32, David Miller wrote: > From: Thomas Gleixner<tglx@linutronix.de> > Date: Thu, 12 Sep 2013 16:43:37 +0200 (CEST) > >> So what about going back to timer_list timers and simply utilize >> register_pm_notifier(), which will tell you that the system resumed? > > The thing to understand is that there are two timeouts for an IPSEC > rule, a soft and a hard timeout. > > There is a gap between these two exactly so that we can negotiate a > new encapsulation with the IPSEC gateway before communication ceases > to be possible over the IPSEC protected path. > > So the idea is that the soft timeout triggers the re-negotiation, > and after a hard timeout the IPSEC path is no longer usable and > all communication will fail. > > Simply triggering a re-negoation after every suspend/resume makes > no sense at all. Spurious re-negotiations are undesirable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (*a*)
What's the differences between this with re-negotiation after every system wall clock changing by using clock_was_set notifier?
> On 2013年08月02日 06:35, David Miller wrote: > > I suspect the thing to do is to have system time changes generate a > notifier when clock_was_set() is called. > > The XFRM code would walk the rules and pretend that we hit the soft > timeout for every rule that we haven't hit the soft timeout yet > already. > > If a rule hit the soft timeout, force a hard timeout. > > When forcing a soft timeout, adjust the hard timeout to be > (hard_timeout - soft_timeout) into the future.
> What we want are real timers. We want that rather than a "we > suspended so just assume all timers expired" event which is not very > useful for this kind of application. >
Here we are facing two problems:)
(1) what kind timer should xfrm_state should employ, Two requirements here: First one, KEY lifetime should include suspend/resume time. Second one, system wall clock time changing(backward/forward) should *not* impact *timer* timeout event(not the soft/hard IPsec events fired to user space!)
net-next commit 99565a6c471cbb66caa68347c195133017559943 ("xfrm: Make xfrm_state timer monotonic") by utilizing *CLOCK_BOOTTIME* has solved this problem.
(2) What I have been bugging you around here for this long time is really the second problem, I'm sorry I didn't make it clearly to you and others, which is below:
Why using wall clock time to calculate soft/hard IPsec events when xfrm_state timer out happens in its timeout handler? Because even if xfrm_state using CLOCK_BOOTTIME, system wall clock time changing will surely disturb soft/hard IPsec events, which you raised your concern about in (*a*).
The initial approach( http://marc.info/?l=linux-netdev&m=137534280429187&w=2) has tried to solve this second problem by eliminating depending system wall clock in xfrm_state timer timeout handler.
I think this time, I have made this situation crystal clear.
-- 浮沉随浪只记今朝笑
--fan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |