Re: New warning in linus/master

["Christophe Leroy (CS GROUP)" <chleroy@kernel.org>]

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@linutronix.de> 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@linutronix.de> 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
>