Bug 208223 - 5.7.3 breaks time horrible - systemd, php sleep() function, tls broken
Summary: 5.7.3 breaks time horrible - systemd, php sleep() function, tls broken
Status: RESOLVED DUPLICATE of bug 208221
Alias: None
Product: Timers
Classification: Unclassified
Component: Realtime Clock (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: timers_realtime-clock
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-18 02:12 UTC by Reindl Harald
Modified: 2020-06-18 10:03 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.7.3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
config used to build 5.7.2 and 5.7.3 (62.00 KB, text/plain)
2020-06-18 02:12 UTC, Reindl Harald
Details

Description Reindl Harald 2020-06-18 02:12:19 UTC
Created attachment 289721 [details]
config used to build 5.7.2 and 5.7.3

with 5.7.3 in a nested VM (VMware ESXi7 on top of VMare Workstation) something goes terrible wrong
systemctl status show crazy values, tls connections not working iperf3 broken

[Thu Jun 18 04:01:14 2020] Kernel command line: root=/dev/sdb1 rootflags=discard rw quiet init=/usr/lib/systemd/systemd systemd.unified_cgroup_hierarchy net.ifnames=0 consoleblank=0 tsc=unstable locale.LANG=C.UTF-8 mitigations=off cgroup_no_v1=all
[Thu Jun 18 04:01:14 2020] tsc: Marking TSC unstable due to boot parameter

basicly that was a Fedora 28 before strip down and replace the kernel long ago
kernel build config attached

----------------------------

this is a php script with negative runtime and sleep() not working properly
OK: 323, TCP-OPEN: 60, UDP-OPEN: 2, RUNTIME: -5387892

nice timejumps for systemd whilerepeated call of "date" is always correct

root@client: systemctl status iperf
● iperf.service - Network-Benchmark
   Loaded: loaded (/usr/lib/systemd/system/iperf.service; static; vendor preset: enabled)
   Active: active (running) since Tue 2021-06-01 18:51:40 CEST; 11 months 13 days left
 Main PID: 598 (iperf3)
    Tasks: 1 (limit: 132)
   Memory: 340.0K
   CGroup: /system.slice/iperf.service
           └─598 /usr/bin/iperf3 -s --port 5201

           root@client: systemctl restart iperf

root@client: systemctl status iperf
● iperf.service - Network-Benchmark
   Loaded: loaded (/usr/lib/systemd/system/iperf.service; static; vendor preset: enabled)
   Active: active (running) since Sun 2020-07-12 17:36:16 CEST; 11 months 5 days ago
 Main PID: 1692 (iperf3)
    Tasks: 1 (limit: 132)
   Memory: 1.4M
   CGroup: /system.slice/iperf.service
           └─1692 /usr/bin/iperf3 -s --port 5201
           
----------------------------

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.7.3

probably that commit does soemthing bad here

commit d7d3023c220d40472adb5789322a91bffb9f6401
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Jun 6 23:51:17 2020 +0200

    x86/vdso: Unbreak paravirt VDSO clocks
    
    commit 7778d8417b74aded842eeb372961cfc460417fa0 upstream.
    
    The conversion of x86 VDSO to the generic clock mode storage broke the
    paravirt and hyperv clocksource logic. These clock sources have their own
    internal sequence counter to validate the clocksource at the point of
    reading it. This is necessary because the hypervisor can invalidate the
    clocksource asynchronously so a check during the VDSO data update is not
    sufficient. If the internal check during read invalidates the clocksource
    the read return U64_MAX. The original code checked this efficiently by
    testing whether the result (casted to signed) is negative, i.e. bit 63 is
    set. This was done that way because an extra indicator for the validity had
    more overhead.
    
    The conversion broke this check because the check was replaced by a check
    for a valid VDSO clock mode.
    
    The wreckage manifests itself when the paravirt clock is installed as a
    valid VDSO clock and during runtime invalidated by the hypervisor,
    e.g. after a host suspend/resume cycle. After the invalidation the read
    function returns U64_MAX which is used as cycles and makes the clock jump
    by ~2200 seconds, and become stale until the 2200 seconds have elapsed
    where it starts to jump again. The period of this effect depends on the
    shift/mult pair of the clocksource and the jumps and staleness are an
    artifact of undefined but reproducible behaviour of math overflow.
    
    Implement an x86 version of the new vdso_cycles_ok() inline which adds this
    check back and a variant of vdso_clocksource_ok() which lets the compiler
    optimize it out to avoid the extra conditional. That's suboptimal when the
    system does not have a VDSO capable clocksource, but that's not the case
    which is optimized for.
    
    Fixes: 5d51bee725cc ("clocksource: Add common vdso clock mode storage")
    Reported-by: Miklos Szeredi <miklos@szeredi.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20200606221532.080560273@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Comment 1 Thomas Gleixner 2020-06-18 06:17:57 UTC
bugzilla-daemon@bugzilla.kernel.org writes:
> probably that commit does soemthing bad here
>
> commit d7d3023c220d40472adb5789322a91bffb9f6401
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Sat Jun 6 23:51:17 2020 +0200
>
>     x86/vdso: Unbreak paravirt VDSO clocks

Probably is not really helpful. Can you please revert it and verify?

Thanks,

        tglx
Comment 2 Reindl Harald 2020-06-18 09:40:14 UTC
could you provide me a "linux-5.7.3.tar.xz" without that patch?
Comment 3 Thomas Gleixner 2020-06-18 10:03:40 UTC

*** This bug has been marked as a duplicate of bug 208221 ***

Note You need to log in before you can comment on or make changes to this bug.