linux-kernel - Re: Time nonlinearity (gettimeofday vs. mtime)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y6ls3vbm.fsf@basil.nowhere.org>
Date:	Fri, 27 Nov 2009 15:18:21 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Matthias Urlichs <matthias@...ichs.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Time nonlinearity (gettimeofday vs. mtime)

Matthias Urlichs <matthias@...ichs.de> writes:

> Lately I've seen this ugliness:

You would probably see it more pronounced on a file system which supports
sub seconds time stamps.

> 13:39:06.000313 clock_gettime(CLOCK_REALTIME, {1259325546, 341196}) = 0 <0.000010>
> 13:39:06.000685 mkdir("/var/tmp/CP_FileTest_TempFolder_d0AOiP/tempFolder1", 0777) = 0 <0.000043>
> 13:39:06.000973 stat64("/var/tmp/CP_FileTest_TempFolder_d0AOiP/tempFolder1", {st_dev=makedev(252, 2), st_ino=1919104, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=501, st_gid=501, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2009/11/27-13:39:05, st_mtime=2009/11/27-13:39:05, st_ctime=2009/11/27-13:39:05}) = 0 <0.000015>
>
> This strace says that st.st_mtime is smaller than time.tv_sec even though the time was acquired earlier.
> Apparently, the problem is that ext3 uses a cached time value for performance.
>
> Question: Is there a reason that the cached time is not updated every time somebody calls gettimeofday() or clock_gettime()?

At least on x86-64 gtod() and clock_gettime() run in user space and 
are unable to update anything in the kernel.

Also in general both calls are extremly time critical and making them
slower for anything else would be a bad idea.

Internally the file systems use the time from last timer tick (=
jiffies), rounded to their granuality. This is needed to avoid non
monotonicity which can break programs. 

In theory the file system could always get the current time, but it
would need to be rounded down anyways for the same reason, so you
would still see the same effect. Also it would be slower of course,
and not really help.

-Andi

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