Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298Ab3IPJBP (ORCPT ); Mon, 16 Sep 2013 05:01:15 -0400 Received: from www.linutronix.de ([62.245.132.108]:46818 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751314Ab3IPJBN (ORCPT ); Mon, 16 Sep 2013 05:01:13 -0400 Date: Mon, 16 Sep 2013 11:01:00 +0200 (CEST) From: Thomas Gleixner To: Fan Du cc: David Miller , herbert@gondor.hengli.com.au, steffen.klassert@secunet.com, dborkman@redhat.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, John Stultz Subject: Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called In-Reply-To: <52365021.8040906@windriver.com> Message-ID: References: <20130912134409.GB21212@gondor.apana.org.au> <20130912.133252.425268707009916773.davem@davemloft.net> <52327C92.5010009@windriver.com> <52365021.8040906@windriver.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-199846746-1379322061=:4089" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2623 Lines: 64 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-199846746-1379322061=:4089 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT 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? Thanks, tglx --8323329-199846746-1379322061=:4089-- -- 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/