Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_setwas called

From: Fan Du
Date: Sun Sep 15 2013 - 20:26:54 EST


Hi, Thomas

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.



Thanks

Thanks,

tglx


--
ææéæåèäæç

--fan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/