Date: Thu, 19 Feb 2015 10:35:31 -0800
From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: john.stultz@linaro.org
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, jstancek@redhat.com
Subject: time / gtod seconds value out of sync?
Message-ID: <20150219183531.GA13745@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1422
Lines: 43

Hi John,

We're seeing an interesting issue with the openposix testcase
difftime/1-1, which basically calls gtod/time, sleeps, calls time/gtod,
then difftime and sees if they disagree. The issue occurs with either
vDSO implementations or direct syscalls.

We are seeing failures on ppc64le and x86_64 (probably other places too,
just not tested yet), because (I'm pretty sure), the time() syscalls
granularity is not accounting for the nsecs value at all. Instead, it
just returns get_seconds().

In one case, I see, in sys_time():

[  313.001823] NACC: timekeeping_get_ns = 1000121642
[  314.001889] NACC: timekeeping_get_ns = 188401

gtod correctly accumulates those nsecs into the secs value:

                ts->tv_sec = tk->xtime_sec;
                nsecs = timekeeping_get_ns(&tk->tkr);
                ts->tv_nsec = 0;
                timespec64_add_ns(ts, nsecs);

but time() does:

		return tk->xtime_sec;

It seems like overkill to do the full timekeeping_get_ns() in time(),
but maybe it's also necessary to account for leap seconds? That is, we
need to ensure that accumulate_nsecs_to_secs() has been called before
return tk->xtime_sec?

Thoughts?

Thanks,
Nish

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/