Re: New warning in linus/master
From: Christophe Leroy (CS GROUP)
Date: Wed Apr 22 2026 - 05:10:14 EST
Le 22/04/2026 à 10:45, Thomas Weißschuh a écrit :
On Wed, Apr 22, 2026 at 04:06:45PM +0800, Ricardo Ribalda wrote:
On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
<thomas.weissschuh@xxxxxxxxxxxxx> wrote:
On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
<thomas.weissschuh@xxxxxxxxxxxxx> wrote:
On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
Media-CI has found a couple of new warnings in the latest kernel
version for aarch64 and powerpc. They get fixed with this patch and
before moving I wanted to know if this was under your radar.
Thanks for the report. I was not aware of these so far.
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 7dec05dd33b7..65914842fae0 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
ifneq ($(c-gettimeofday-y),)
- CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
+ CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
-Wno-maybe-uninitialized
endif
(...)
I'd like to know exactly what is going on before suppressing the warning.
It is a non-standard warning, only enabled by *some* of the vDSO builds
for some reason.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fusers%2Fribalda%2F-%2Fpipelines%2F1649144%2Ftest_report%3Fjob_name%3Dcross-gcc&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7cbf9009269d4ddc16d208dea04b86f1%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124443421115079%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O4r8HjaUn7KEgW8tDE9GEC9e8CWyJBpCfhVTJZZ%2BFHs%3D&reserved=0
While I was able to download a configuration from this job and also use the
same container image, I can not reproduce the issue. Is the configuration the
full one or only the template?
Could you provide full reproduction steps?
You can try repro with:
work/linux $ podman run -v .:/workdir/ --rm -it
registry.freedesktop.org/linux-media/media-ci/build:latest
$ cd /workdir
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
arch/arm64/kernel/vdso/vgettimeofday.o
The gcc version discrepancy is because I the error was due to old gcc
version and I was playing around with that... but it fails in both
gcc14 and gcc15
Ack.
You can try with debian testing with
work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
$ apt-get update
$ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
$ cd /workdir
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
arch/arm64/kernel/vdso/vgettimeofday.o
Both reproducers do *not* reproduce the issue for me.
(It is more or less exactly what I tried before)
Ok, I think I found what is going on. media-ci was forcing
KCFLAGS=-Wmaybe-uninitialized
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fmedia-ci%2F-%2Fblob%2Fmain%2Ftest-build.sh%3Fref_type%3Dheads%23L29&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7cbf9009269d4ddc16d208dea04b86f1%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124443421146576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FpTHYfCn5ob42%2Fm6FVOZ32PVzuXBNBT3rlMVWslCfhw%3D&reserved=0
And something has changed in the kernel in the last version that
triggers a (hopefully) false positive.
can you try with:
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized allyesconfig
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized prepare
That works!
The warning was introduced in ed78b7b2c5ae ("vdso/gettimeofday: Add a helper to
read the sequence lock of a time namespace aware clock").
It is *not* a false-positive, specifically:
do {
if (vdso_read_begin_timens(vc, &seq)) {
vd = __arch_get_vdso_u_timens_data(vd);
vc = &vd->aux_clock_data[idx];
/* Re-read from the real time data page */
continue;
This 'continue' jumps to the end of the loop body and if the real vDSO datapage
by chance has a sequence counter of '1' will exit the loop, leaving 'sec' and
'nsec' uninitialized. My believe was that the 'continue' would jump to the
*beginning* of the loop body, which is cleary wrong. Previously there was an
inner while loop() which would make the 'continue' effectively start at the
beginning of the outer do-while loop.
Well spotted. I missed it too while reviewing.
A 'retry:' label at the begining of the loop with a 'goto retry' instead of the 'continue' should make it.
Christophe
}
/* Auxclock disabled? */
if (vc->clock_mode == VDSO_CLOCKMODE_NONE)
return false;
if (!vdso_get_timestamp(vd, vc, VDSO_BASE_AUX, &sec, &ns))
return false;
} while (vdso_read_retry(vc, seq));
vdso_set_timespec(ts, sec, ns);
I'm working on a fix.
Thomas