netdev - Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52365021.8040906@windriver.com>
Date:	Mon, 16 Sep 2013 08:26:09 +0800
From:	Fan Du <fan.du@...driver.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	David Miller <davem@...emloft.net>, <herbert@...dor.hengli.com.au>,
	<steffen.klassert@...unet.com>, <dborkman@...hat.com>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set
 was called

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html