raw_skew test in timers from ubuntu_kernel_selftests Bail out on B-4.15

It looks like this issue is a bit random.

I tried to run it on 4.15.0-102 and 4.15.0-103, they all got skipped with:
 selftests: raw_skew
 ========================================
 WARNING: ADJ_OFFSET in progress, this will cause inaccurate results
 Estimating clock drift: 12.142(est) 11.73(act) [SKIP]
 1..0 # Skipped: The clock was adjusted externally. Shutdown NTPd or other time sync daemons
 not ok 1..7 selftests: raw_skew [SKIP]

Let's keep an eye on this issue.

Spotted on Eoan 5.3
5.3.0-64.58 With node rizzo

Found on B-4.15 (4.15.0-1080.84) AWS with instance t3a.2xlarge only

Found on Bionic/aws 4.15.0-1095.102

Also seen in bionic linux-gcp-fips 4.15.0-2007.8 for sru-20210315

Found on bionic/linux-aws-fips: 4.15.0-2045.47

Found on bionic/linux-azure-4.15/4.15.0-1123.136 on Standard_B1ms instance only:
----
Estimating clock drift: 62.230(est) 71.696(act) [FAILED]
Bail out!
----

Found on 2021.11.08/bionic/linux-azure-4.15/4.15.0-1127.140:

17149 14:54:24 DEBUG| [stdout] selftests: raw_skew
17150 14:54:24 DEBUG| [stdout] ========================================
17151 14:56:24 DEBUG| [stdout] Estimating clock drift: 9.90(est) 19.661(act) [FAILED]
17152 14:56:24 DEBUG| [stdout] Bail out!

Found on bionic/linux-aws: 4.15.0-1116.123

Found on 2022.01.31/impish/kvm/5.13.0-1013.14 and 2022.01.31/bionic/kvm/4.15.0-1107.109 and is failing with

19:54:27 DEBUG| [stdout] # selftests: timers: raw_skew
19:56:27 DEBUG| [stdout] # Estimating clock drift: 43.443(est) 0.0(act) [FAILED]
19:56:27 DEBUG| [stdout] # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
19:56:27 DEBUG| [stdout] not ok 1 selftests: timers: raw_skew # exit=1

This passed in other cycles with # Estimating clock drift: 0.0(est) 0.0(act) [OK]
but is now failing because it seems the function clock_gettime* in the test is now actually returning a value when it was not before.

Regardless this seems like a case of vm clock flakiness. Maybe something in glibc changed that caused this to finally return a value for some reason? Havent looked into it too much but doesent seem like a kernel issue.