From: Fan Du <fan.du@windriver•com>
To: Thomas Gleixner <tglx@linutronix•de>
Cc: David Miller <davem@davemloft•net>,
<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: Tue, 17 Sep 2013 15:47:26 +0800 [thread overview]
Message-ID: <5238090E.9000703@windriver.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1309161059220.4089@ionos.tec.linutronix.de>
On 2013年09月16日 17:01, Thomas Gleixner wrote:
> On Mon, 16 Sep 2013, Fan Du wrote:
>> On 2013年09月13日 22:32, Thomas Gleixner wrote:
>>> On Fri, 13 Sep 2013, Fan Du wrote:
>>>> (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*).
>>>
>>> No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
>>> basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
>>> well. So without a suspend/resume cycle CLOCK_MONOTONIC and
>>> CLOCK_BOOTTIME are the same. After a suspend/resume cycle
>>> CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
>>> the number of seconds spent in suspend.
>>
>> Sorry for the ambiguity. Yes, CLOCK_BOOTTIME is monotonic *and* counting
>> suspend/resume time as well as not affected by wall clock time change.
>>
>> Using CLOCK_BOOTTIME guarantees b- will timeout in a right manner, i.e., not
>> affected by wall clock time change, as well as keep the timer valid when
>> suspend/resume.
>>
>> A classic way of using timer is:
>> a- Arm a timer with specified interval
>> b- Wait for the timer to timeout
>> c- After the timeout, notify the event to other place in the timer handler.
>>
>> IPsec key lifetime timer does its this way:
>> a- Arm a timer with specified interval
>> b- Wait for the timer to timeout
>> c- After timeout, in the timer handler, using wall clock time to calculate
>> which kind of event to notify user(soft or hard for both key use time,
>> and key created time). So the problem arises at this stage if wall clock
>> time changed.
>
> And why on earth must it use wall clock time for selecting the event
> type?
/*shivering... sorry to bother you again.*/
Yep, it's a bit twisted. This parts of codes come a long way from v2.5.67
Beyond this fact, I barely know its original design goal by doing so.
The first version of this patch is to remove the wall clock time things
by myself, it's a pity that the feedback is not very welcome at the end.
So later on adding notifier at clock_was_set is suggested by David.
> Thanks,
>
> tglx
--
浮沉随浪只记今朝笑
--fan
next prev parent reply other threads:[~2013-09-17 7:47 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
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 [this message]
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=5238090E.9000703@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