Messages in this thread | | | Date | Thu, 12 Jun 2014 02:36:24 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [patch 13/13] tomoyo: Use sensible time interface |
| |
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
| |