All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fan Du <fan.du@windriver.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
	David Miller <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	Daniel Borkmann <dborkman@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
Date: Tue, 20 Aug 2013 09:56:26 +0800	[thread overview]
Message-ID: <5212CCCA.4090907@windriver.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1308181102230.4089@ionos.tec.linutronix.de>



On 2013年08月18日 17:05, Thomas Gleixner wrote:
> On Wed, 14 Aug 2013, Fan Du wrote:
>
>>  From e3929d4fdfad5b40fd8cad0e217597670d1aef54 Mon Sep 17 00:00:00 2001
>> From: Fan Du<fan.du@windriver.com>
>> Date: Wed, 14 Aug 2013 16:39:23 +0800
>> Subject: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was
>> called
>>
>> When clock_was_set is called in case of system wall time change
>> or host resume from suspend state, use this notifier for places
>> where interested in this action, e.g Ipsec SA lifetime management.
>
> Sigh. These notifiers have been proposed in the past and we always
> rejected them. Why do you need this? There should be nothing except
> the core timekeeping code which needs to know about clock_was_set.
>
> Can you please explain what kind of users you have in mind and WHY
> they need to know about it.

Hi, Thomas


Thanks for your patience. Please let me take a few seconds try to
explain this.

Current xfrm layers has *one* hrtimer to guard Ipsec keys timeout,
The timeout could be measured in either of below two ways:

  (1) The timer is started once the keys is created, but this
      key is not necessary actually used right now. In detail,
      record the get_seconds() when this key is created.

  (2) Starting the timer when this key is actually used, e.g when
      an IP packet need to be encrypted. In details, recored the
      get_seconds() when this key is first used.

So in the hrtimer handler, the code get current get_seconds, and
check against with what saved in (1)or(2), and notify the timeout
up to user land.

So the pitfall is using one hrtimer for two timeout events,
most importantly using get_seconds to check timeout, once system
clock is changed by user intentionally, the key timeout could
misbehave wildly.

A refractor has been proposed to get rid of depending on system wall
clock by cleaning up the hrtimer handler. Unfortunately David frowned
on it in (3), and suggest once system clock is changed, adjust the
timeout of the key.


(3): http://www.spinics.net/lists/netdev/msg245169.html


> Thanks,
>
> 	tglx
>

-- 
浮沉随浪只记今朝笑

--fan

  reply	other threads:[~2013-08-20  1:56 UTC|newest]

Thread overview: 31+ 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 [this message]
2013-09-12 13:21               ` Thomas Gleixner
2013-09-12 13:44                 ` Herbert Xu
2013-09-12 13:44                   ` Herbert Xu
2013-09-12 14:43                   ` Thomas Gleixner
2013-09-12 14:43                     ` Thomas Gleixner
2013-09-12 17:32                     ` David Miller
2013-09-12 17:32                       ` David Miller
2013-09-12 19:37                       ` Thomas Gleixner
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
2013-09-12 20:35                   ` John Stultz
2013-09-12 20:35                     ` John Stultz
2013-09-12 20:41                     ` Thomas Gleixner
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=5212CCCA.4090907@windriver.com \
    --to=fan.du@windriver.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=herbert@gondor.hengli.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.