Linux s390 Architecture development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH 01/15] vdso: Move the kernel-side time update helpers to a new header
Date: Wed, 09 Sep 2026 09:03:00 +0000	[thread overview]
Message-ID: <20260909090301.3D2A51F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260909-vdso-asm-generic-vsyscall-h-v1-1-63ae856cc659@linutronix.de>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] The kerneldoc for `vdso_time_update_begin()` still references the old function name `vdso_update_end()` instead of `vdso_time_update_end()`.

Pre-existing issues:
- [High] kvm_clock_sync() accesses KVM's vm_list locklessly during stop_machine(), which can race with VM creation/destruction and traverse a corrupted list.
--

commit a658f5b7a653ebec860c6e97f450e6c3c3e5c2a1
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

vdso: Move the kernel-side time update helpers to a new header

The vdso/ header namespace is meant for symbols which are usable from
vDSO userspace code. However vdso_update_begin() and vdso_update_end()
are only usable from the kernel. Move them into a new header in the
linux/ namespace. Also rename them to make clear that they are only
for time-related data.

> diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
> index 2b989bebd220a..161628f6906fe 100644
> --- a/arch/s390/kernel/time.c
> +++ b/arch/s390/kernel/time.c
> @@ -527,7 +528,7 @@ static int stp_sync_clock(void *data)
>  			cpu_relax();
>  		rc = 0;
>  		if (stp_info.todoff || stp_info.tmd != 2) {
> -			flags = vdso_update_begin();
> +			flags = vdso_time_update_begin();
>  			rc = chsc_sstpc(stp_page, STP_OP_SYNC, 0,
>  					&clock_delta);
>  			if (rc == 0) {
>  				sync->clock_delta = clock_delta;
>  				clock_sync_global(clock_delta);

[Severity: High]
This isn't a bug introduced by this patch, but is a pre-existing severe
issue. Does stp_sync_clock() running via stop_machine() race with VM
creation or destruction and lead to list corruption?

If a task is preempted while modifying vm_list under kvm_lock during VM
creation or destruction (since kvm_lock is a mutex and leaves preemption
enabled), the list pointers could be left in an inconsistent state.

Because stp_sync_clock() runs via stop_machine(), it can preempt such tasks.
stp_sync_clock() calls clock_sync_global(), which triggers the epoch notifier
and causes kvm_clock_sync() to blindly traverse the corrupted vm_list
locklessly:

arch/s390/kvm/s390.c:kvm_clock_sync() {
    ...
    list_for_each_entry(kvm, &vm_list, vm_list) {
    ...
}

Can this lead to a host kernel panic or an infinite loop during lockless
traversal?

>  				rc = __store_stpinfo();
>  				if (rc == 0 && stp_info.tmd != 2)
>  					rc = -EAGAIN;
>  			}
> -			vdso_update_end(flags);
> +			vdso_time_update_end(flags);
>  		}
>  		sync->in_sync = rc ? -EAGAIN : 1;
>  		xchg(&first, 0);

[ ... ]

> diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c
> index aa59919b8f2c2..12e205d86e7f3 100644
> --- a/kernel/time/vsyscall.c
> +++ b/kernel/time/vsyscall.c
> @@ -177,7 +178,7 @@ void vdso_time_update_aux(struct timekeeper *tk)
>  #endif
>  
>  /**
> - * vdso_update_begin - Start of a VDSO update section
> + * vdso_time_update_begin - Start of a VDSO update section
>   *
>   * Allows architecture code to safely update the architecture specific VDSO
>   * data. Disables interrupts, acquires timekeeper lock to serialize against
> @@ -188,7 +189,7 @@ void vdso_time_update_aux(struct timekeeper *tk)
>   * Returns: Saved interrupt flags which need to be handed in to
>   * vdso_update_end().
     ^^^^^^^^^^^^^^^
>   */
> -unsigned long vdso_update_begin(void)
> +unsigned long vdso_time_update_begin(void)

[Severity: Low]
Should the kerneldoc for vdso_time_update_begin() be updated to reference
vdso_time_update_end() instead of vdso_update_end()?

>  {
>  	struct vdso_time_data *vdata = vdso_k_time_data;
>  	unsigned long flags = timekeeper_lock_irqsave();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-vdso-asm-generic-vsyscall-h-v1-0-63ae856cc659@linutronix.de?part=1

  reply	other threads:[~2026-09-09  9:03 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09  8:51 [PATCH 00/15] vdso: Clean up the vsyscall.h headers Thomas Weißschuh
2026-09-09  8:51 ` [PATCH 01/15] vdso: Move the kernel-side time update helpers to a new header Thomas Weißschuh
2026-09-09  9:03   ` sashiko-bot [this message]
2026-09-09  8:51 ` [PATCH 02/15] vdso/gettimeofday: Define fallback __arch_get_vdso_u_time_data() in gettimeofday.c Thomas Weißschuh
2026-09-09  8:57   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 03/15] vdso/getrandom: Define fallback __arch_get_vdso_u_rng_data() in getrandom.c Thomas Weißschuh
2026-09-09  8:54   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 04/15] vdso/vsyscall: Define fallback time synchronization functions in vsyscall.c Thomas Weißschuh
2026-09-09  9:13   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 05/15] vdso: Delete asm-generic/vdso/vsyscall.h Thomas Weißschuh
2026-09-09  8:54   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 06/15] x86/vdso: Move vDSO page definitions to asm/vdso.h Thomas Weißschuh
2026-09-09  9:00   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 07/15] sparc/vdso: Move __VDSO_PAGES " Thomas Weißschuh
2026-09-09  9:01   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 08/15] s390/vdso: Delete asm/vdso/vsyscall.h inclusions Thomas Weißschuh
2026-09-09  8:56   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 09/15] sparc/vdso: Delete asm/vdso/vsyscall.h inclusion Thomas Weißschuh
2026-09-09  8:55   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 10/15] x86/vdso: Delete asm/vdso/vsyscall.h inclusions Thomas Weißschuh
2026-09-09  9:02   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 11/15] arm64/vdso: " Thomas Weißschuh
2026-09-09  8:56   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 12/15] riscv/hwprobe: Include vdso/datapage.h Thomas Weißschuh
2026-09-09  8:55   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 13/15] vdso: Remove unnecessary vdso/vsyscall.h includes Thomas Weißschuh
2026-09-09  9:01   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 14/15] vdso: Add asm-generic/vdso/vsyscall.h Thomas Weißschuh
2026-09-09  9:04   ` sashiko-bot
2026-09-09  8:51 ` [PATCH 15/15] vdso: Remove __ASSEMBLER__ guards from vsyscall.h Thomas Weißschuh
2026-09-09  9:00   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260909090301.3D2A51F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=thomas.weissschuh@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox