From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755170AbaFLAgl (ORCPT ); Wed, 11 Jun 2014 20:36:41 -0400 Received: from www.linutronix.de ([62.245.132.108]:36230 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752875AbaFLAgj (ORCPT ); Wed, 11 Jun 2014 20:36:39 -0400 Date: Thu, 12 Jun 2014 02:36:24 +0200 (CEST) From: Thomas Gleixner To: John Stultz cc: LKML , Peter Zijlstra , Ingo Molnar , Kentaro Takeda , linux-security-module@vger.kernel.org Subject: Re: [patch 13/13] tomoyo: Use sensible time interface In-Reply-To: Message-ID: References: <20140611234024.103571777@linutronix.de> <20140611234607.775273584@linutronix.de> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Jun 2014, John Stultz wrote: > On Wed, Jun 11, 2014 at 5:22 PM, Thomas Gleixner wrote: > > On Wed, 11 Jun 2014, John Stultz wrote: > > > >> On Wed, Jun 11, 2014 at 4:59 PM, Thomas Gleixner 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