Message-ID: <52327C92.5010009@windriver.com>
Date:	Fri, 13 Sep 2013 10:46:42 +0800
From:	Fan Du <fan.du@...driver.com>
To:	David Miller <davem@...emloft.net>, <tglx@...utronix.de>
CC:	<herbert@...dor.hengli.com.au>, <steffen.klassert@...unet.com>,
	<dborkman@...hat.com>, <linux-kernel@...r.kernel.org>,
	<netdev@...r.kernel.org>, John Stultz <john.stultz@...aro.org>
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@...utronix.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists