From: Fan Du <fan.du@windriver•com>
To: David Miller <davem@davemloft•net>, <tglx@linutronix•de>
Cc: <herbert@gondor•hengli.com.au>, <steffen.klassert@secunet•com>,
<dborkman@redhat•com>, <linux-kernel@vger•kernel.org>,
<netdev@vger•kernel.org>, John Stultz <john.stultz@linaro•org>
Subject: Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
Date: Fri, 13 Sep 2013 10:46:42 +0800 [thread overview]
Message-ID: <52327C92.5010009@windriver.com> (raw)
In-Reply-To: <20130912.133252.425268707009916773.davem@davemloft.net>
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
next prev parent reply other threads:[~2013-09-13 2:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 9:04 [RFC PATCHv2 0/3] xfrm: Refactor xfrm_state timer management Fan Du
2013-08-07 9:04 ` [RFC PATCHv2 1/3] hrtimer: Add notifer for clock_was_set Fan Du
2013-08-07 9:20 ` Daniel Borkmann
2013-08-07 9:31 ` Fan Du
2013-08-07 9:35 ` Daniel Borkmann
2013-08-14 8:52 ` [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called Fan Du
2013-08-14 19:04 ` Sergei Shtylyov
2013-08-18 9:05 ` Thomas Gleixner
2013-08-20 1:56 ` Fan Du
2013-09-12 13:21 ` Thomas Gleixner
2013-09-12 13:44 ` Herbert Xu
2013-09-12 14:43 ` Thomas Gleixner
2013-09-12 17:32 ` David Miller
2013-09-12 19:37 ` Thomas Gleixner
2013-09-13 2:46 ` Fan Du [this message]
2013-09-13 14:32 ` Thomas Gleixner
2013-09-16 0:26 ` Fan Du
2013-09-16 9:01 ` Thomas Gleixner
2013-09-17 7:47 ` Fan Du
2013-09-12 20:35 ` John Stultz
2013-09-12 20:41 ` Thomas Gleixner
2013-08-07 9:04 ` [RFC PATCHv2 2/3] xfrm: Update xfrm_state lifetime expire after clock_was_set Fan Du
2013-08-14 5:26 ` [PATCHv3 net-next ] " Fan Du
2013-08-14 11:04 ` Steffen Klassert
2013-08-07 9:04 ` [RFC PATCHv2 3/3] xfrm: Revert "Fix unexpected SA hard expiration after changing date" Fan Du
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52327C92.5010009@windriver.com \
--to=fan.du@windriver$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dborkman@redhat$(echo .)com \
--cc=herbert@gondor$(echo .)hengli.com.au \
--cc=john.stultz@linaro$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=steffen.klassert@secunet$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox