From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E0754385800C; Tue, 21 Mar 2023 15:06:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E0754385800C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679411218; bh=Bgk9+OQYIORAv2IVokkVTBi4uvZYx0vJcpobLt9PsLM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lOfLdRmVhnaIAVnD90VDxi/2cV4OSqEmOryE2LF3gMcsAivI6hNjDYzKpL7c+HlIJ V+3/m9+lrnn8t0iibVyC+3o07TdASVjkBY6CCNMdUf9yhtobqL92F3ehW644Jdm7rO 0egKjfWJC8qziVrNqmjKe5p2jzlFD/kTk3L1g4mU= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug time/30200] time sometimes appears to go backwards Date: Tue, 21 Mar 2023 15:06:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: time X-Bugzilla-Version: 2.35 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30200 --- Comment #12 from Adhemerval Zanella --- Thanks for the detailed (In reply to eggert from comment #11) > (In reply to Florian Weimer from comment #10) > > Is this actually causing application problems...? >=20 > In theory any sequence of timestamps is something that a (perverse) sysad= min > could inflict on the user by constantly futzing with the system clock, and > hence applications that generate out-of-order timestamps are allowed by > POSIX. >=20 > In practice out-of-order timestamps are problematic. Users will likely be > confused, for example, if a log of a thread's actions contain out-of-order > timestamps even when the system clock was not reset. >=20 > I looked at a few applications. >=20 > * Git can issue out-of-order timestamps. It's complicated enough that I > judged it simpler to fix the problem than worry about how serious it is, = and > filed a proposed patch to do that > #u>. >=20 > * GNU Make can issue out-of-order timestamps in a debugging log - not a > serious problem but it could be annoying. I filed a proposed patch > . >=20 > * Gnulib can generate out-of-order timestamps when parsing old-fashioned > time strings, causing glitches in Gnulib-using commands like 'touch 01010= 000 > file'. This is not serious (hardly anybody uses those old POSIX-specified > strings that do not specify year numbers) and I don't know whether it's a > POSIX violation. I fixed that problem > and the fix > should propagate into future releases of Coreutils etc. >=20 > * GNU Emacs proper does not have the problem with Glibc (it may have it w= ith > MS-Windows but that=E2=80=99s out of scope here). One Emacs auxiliary pro= gram > =E2=80=98movemail=E2=80=99 may have the issue since it does call =E2=80= =98time=E2=80=99. I haven=E2=80=99t > investigated further. >=20 > The result of this brief investigation: >=20 > * There are problems. >=20 > * Effects observed so far are small (e.g., logs out of order). >=20 > * GNU Make (my first worry, due to its extensive use of timestamps) seems= to > be mostly OK. >=20 > * Any big effects are surely either rare, or hard to trace back to the > problem source (or both); if big effects were common and easily traced ba= ck, > we=E2=80=99d know already. >=20 > As an application developer I=E2=80=99d rather see =E2=80=98time=E2=80=99= fixed to match > =E2=80=98gettimeofday=E2=80=99 / CLOCK_REALTIME / etc., as I worry that t= here might be > larger, rare effects that this little survey didn=E2=80=99t catch. Thanks for the detailed analysis Paul, and I completely agree with you that this is problematic and I really can't see why Florian sees the performance the penalty is worth all this trouble (he even hinted that if we ever get=20 this upstream he would need to revert to RHEL and related distros). Specia= lly because if the user really wants to, it can simply do: #define time(__ptr) \ {( \ struct timespec __ts; \ clock_gettime (CLOCK_REALTIME_COARSE, &__ts); \ __ts.tv_sec; \ )} On most architectures that provide vDSO, this should only be marginally slo= wer than time. Also, the problem is not really specific for glibc 2.31+. Rather, on glibc= =20 2.30 and older, the time syscall is used if present (which always uses the coarse timer), otherwise gettimeofday is used. The time syscall is supported on: $ python sysdeps/unix/sysv/linux/glibcsyscalls.py query-syscall time time: defined: hppa i386 m68k microblaze mips/mips32 powerpc/powerpc32 powerpc/powerpc64 s390/s390-32 sh sparc/sparc32 x86_64/64 x86_64/x32 undefined: aarch64 alpha arc arm csky ia64 loongarch mips/mips64/n32 mips/mips64/n64 nios2 or1k riscv/rv32 riscv/rv64 s390/s390-64 sparc/sparc64 So on 2.30 we have a different problem where different architectures used different timers for 'time' and it was fixed on 2.31 to always use=20 CLOCK_REALTIME_COARSE. So this problem *always* existed (which also makes ponder if this bug is really urgent as you and Bruno are trying to pose by pushing multiple fixes on different projects). --=20 You are receiving this mail because: You are on the CC list for the bug.=