All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: John Stultz <john.stultz@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Kentaro Takeda <takedakn@nttdata.co.jp>,
	linux-security-module@vger.kernel.org
Subject: Re: [patch 13/13] tomoyo: Use sensible time interface
Date: Thu, 12 Jun 2014 02:36:24 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1406120232050.5170@nanos> (raw)
In-Reply-To: <CALAqxLVTAsxPkZ052xtMPwkM+yFfPcfrzf71Jok4SYq5VWh-cQ@mail.gmail.com>

On Wed, 11 Jun 2014, John Stultz wrote:
> On Wed, Jun 11, 2014 at 5:22 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Wed, 11 Jun 2014, John Stultz wrote:
> >
> >> On Wed, Jun 11, 2014 at 4:59 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> > There is no point in calling gettimeofday if only the seconds part of
> >> > the timespec is used. Use get_seconds() instead. It's not only the
> >> > proper interface it's also faster.
> >>
> >> My only caution here is you only get tick-granular time here. So if
> >> the second rolled over after the last tick, you'd get the previous
> >> second when you call get_seconds(). This can cause some surprising
> >> effects if the get_seconds() return value is mixed with clocksource
> >> granular gettimeofday() calls.
> >
> > If the whole thing only cares about the seconds value, then where is
> > the problem?
> >
> > Even if you call gettimeofday() then you still can observe this
> >
> > gettimeofday(ts)
> >         ts.tv_sec = 99
> >         ts.tv_nsec = 999999999
> >
> > So if you readout the related value ONE nanosecond later, then this
> > value will have
> >         ts.tv_sec = 100
> >         ts.tv_nsec = 0
> >
> > So what's the point? The tomoyo code chose to take seconds granular
> > time stamps for whatever reasons. So it should be able to deal with
> > that, right?
> 
> No, the problem I'm warning about is if they were using gettimeofday()
> elsewhere in relation to those timestamps, they could see something
> like:
> 
> do_gettimeofday()  { 99, 888....}
> get_seconds()   { 99 }
> do_gettimeofday()  { 99, 999....}
> get_seconds()   { 99 }
> do_gettimeofday()  { 100, 000....}
> get_seconds()   { 99 }
> do_gettimeofday()  { 100, 011....}
> get_seconds()   { 100 }
> 
> This is the same problem people come across occasionally if they call
> gettimeofday, then create a file and fret that the file's timestamp
> seems to be before the gettimefoday call, and its all due to comparing
> timestamps with different granularities.
> 
I'm aware of that, but there are only two places in that code which
deal with time and both are calling do_gettimeofday and both just use
the tv_sec part of it. And both of them are statistics.

One part of says clearly:

        * I don't use atomic operations because race condition is not fatal.

Thanks,

	tglx



  reply	other threads:[~2014-06-12  0:36 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11 23:59 [patch 00/13] time: Tree wide cleanup of interfaces and crap Thomas Gleixner
2014-06-11 23:59 ` [patch 01/13] acct: Use ktime_get_ts() Thomas Gleixner
2014-06-21 20:36   ` [tip:timers/core] " tip-bot for Thomas Gleixner
2014-06-11 23:59 ` [patch 02/13] tsacct: " Thomas Gleixner
2014-06-21 20:37   ` [tip:timers/core] " tip-bot for Thomas Gleixner
2014-06-11 23:59 ` [patch 03/13] delayacct: " Thomas Gleixner
2014-06-21 20:36   ` [tip:timers/core] " tip-bot for Thomas Gleixner
2014-06-11 23:59 ` [patch 05/13] sound: " Thomas Gleixner
2014-06-12 10:42   ` Takashi Iwai
2014-06-12 10:51     ` Thomas Gleixner
2014-06-12 10:59       ` Takashi Iwai
2014-06-11 23:59 ` [patch 04/13] net: mac80211: " Thomas Gleixner
2014-06-11 23:59   ` Thomas Gleixner
2014-06-12  6:53   ` Johannes Berg
2014-06-12  9:03     ` Luis R. Rodriguez
2014-06-12  9:03       ` [Cocci] " Luis R. Rodriguez
2014-06-12  9:51       ` Julia.Lawall
2014-06-12  9:51         ` Julia.Lawall at lip6.fr
2014-06-12 10:49         ` Thomas Gleixner
2014-06-12 10:49           ` Thomas Gleixner
2014-06-11 23:59 ` [patch 06/13] sound: intel8x0: Use ktime and ktime_get() Thomas Gleixner
2014-06-11 23:59 ` [patch 08/13] firewire: Use ktime_get_ts() Thomas Gleixner
2014-06-12 12:35   ` Stefan Richter
2014-06-12 14:12     ` Thomas Gleixner
2014-06-21 20:37   ` [tip:timers/core] " tip-bot for Thomas Gleixner
2014-06-11 23:59 ` [patch 07/13] kdb: " Thomas Gleixner
2014-06-21 20:37   ` [tip:timers/core] " tip-bot for Thomas Gleixner
2014-06-11 23:59 ` [patch 10/13] time: Remove do_posix_clock_monotonic_gettime() Thomas Gleixner
2014-06-11 23:59 ` [patch 09/13] fork: Use ktime_get_ts() Thomas Gleixner
2014-06-21 20:37   ` [tip:timers/core] " tip-bot for Thomas Gleixner
2014-06-11 23:59 ` [patch 11/13] wireless: mwifiex: Use the proper interfaces Thomas Gleixner
2014-06-11 23:59   ` Thomas Gleixner
2014-06-12  3:22   ` Bing Zhao
2014-06-12  8:31     ` [patch V2] " Thomas Gleixner
2014-06-12  8:38       ` Johannes Berg
2014-06-13 18:28         ` Bing Zhao
2014-06-13 18:28           ` Bing Zhao
2014-06-11 23:59 ` [patch 12/13] net: mac80211: Remove silly timespec dance Thomas Gleixner
2014-06-11 23:59   ` Thomas Gleixner
2014-06-12  6:49   ` Johannes Berg
2014-06-12  8:19     ` Thomas Gleixner
2014-06-12  8:35       ` net_timedelta() affected by settimeofday() (was: [patch 12/13] net: mac80211: Remove silly timespec dance) Johannes Berg
2014-06-12  8:39         ` Johannes Berg
2014-06-12  8:57           ` Thomas Gleixner
2014-06-12  9:21             ` Johannes Berg
2014-06-12 14:09               ` Thomas Gleixner
2014-06-12 14:09                 ` Thomas Gleixner
2014-06-13 17:58                 ` Johannes Berg
2014-06-11 23:59 ` [patch 13/13] tomoyo: Use sensible time interface Thomas Gleixner
2014-06-12  0:08   ` John Stultz
2014-06-12  0:22     ` Thomas Gleixner
2014-06-12  0:28       ` John Stultz
2014-06-12  0:36         ` Thomas Gleixner [this message]
2014-06-12 11:53   ` Tetsuo Handa
2014-06-21 20:37   ` [tip:timers/core] " tip-bot for Thomas Gleixner

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=alpine.DEB.2.10.1406120232050.5170@nanos \
    --to=tglx@linutronix.de \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=takedakn@nttdata.co.jp \
    /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.