Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755647Ab3IPA0w (ORCPT ); Sun, 15 Sep 2013 20:26:52 -0400 Received: from mail1.windriver.com ([147.11.146.13]:62231 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755179Ab3IPA0v (ORCPT ); Sun, 15 Sep 2013 20:26:51 -0400 Message-ID: <52365021.8040906@windriver.com> Date: Mon, 16 Sep 2013 08:26:09 +0800 From: Fan Du User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Thomas Gleixner CC: David Miller , , , , , , John Stultz Subject: Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called References: <20130912134409.GB21212@gondor.apana.org.au> <20130912.133252.425268707009916773.davem@davemloft.net> <52327C92.5010009@windriver.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [128.224.162.195] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2181 Lines: 62 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/