From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 072E830C618 for ; Fri, 15 May 2026 19:48:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778874484; cv=none; b=liFnmAuogvlmY/cyg0UVySlcgOZ2AubdOpSm2XqZwvptTZdMx38P+ALP9fQcrvdxOCxzQjVHUrriudYroluU6l1XelBKE1r7TtU7IC4RYVfLcFMctSbhJM13NAUWcR+UCUfzUlhJZbxvSsUgb1+vNfVBqJSd/yK/vRDwyGu8gC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778874484; c=relaxed/simple; bh=0QSUHS8m/mRg91U7jSuorHZ7kkONYCPuPv4941aXup0=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=HjyVVSBvgmxo2uqtTfcR/0V0erVTKVH0QMnRxtLLl8VqdDIbrAw0RbnVZFOp+AR+IVF412mu1d+kYpIUVGPOOIMTUnfN9DxNHF7l4pfYlziXHdKUoWUOThTZ4IA5rb/qi8ceRpbKj98zTzFd70dhIAbkgjK7Xx8Q/uo11mcqXwE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V8YVbpvx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V8YVbpvx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D898C2BCB0; Fri, 15 May 2026 19:48:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778874483; bh=0QSUHS8m/mRg91U7jSuorHZ7kkONYCPuPv4941aXup0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=V8YVbpvxWG6Ioj+LNW3sbzOni6ObrCLcmSiikFbSS3aNiG23G/SjK3GLjTnVfXm5+ 3Zqi0lOMBRSiAw5YQV+9C0D7XgqTtWYm04UQWU1dsA4LLpCEzBgGoxL3Vo9C2Yer7E EqthdLNZ3vBCztvKO2e7lvZu8uZaXdvrpI83FeH5l0l6+e6hQNulpdfol1kIcs9Nxt 8ZLGBm0qQVlqrl5VbAnS8tFaKBCXEi9yd8yfvHYPr3b4iA5wgEwgenkU6AdxMNs2Q4 CvJKgo2j4HXsnWq4HIKc7aruUPe+2KP6RnQvXzt2FFTkycZR+2TLsGFD/yMzZQdTyY 1vP6TcMUWK7Dg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 15/41] x86/xen/time: Nullify x86_platform's sched_clock save/restore hooks Reply-To: sashiko-reviews@lists.linux.dev To: "Sean Christopherson" Cc: linux-hyperv@vger.kernel.org In-Reply-To: <20260515191942.1892718-16-seanjc@google.com> References: <20260515191942.1892718-16-seanjc@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2026 19:48:02 +0000 Message-Id: <20260515194803.1D898C2BCB0@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] Setting `x86_platform.save_sched_clock_state` and `x86_platform.re= store_sched_clock_state` to NULL causes an unconditional NULL pointer deref= erence during suspend, hibernation, or kexec operations in Xen guests. -- commit 07d607146953d7a7f53a708d78545184418c340c Author: Sean Christopherson Subject: x86/xen/time: Nullify x86_platform's sched_clock save/restore hooks This commit nullifies the x86_platform sched_clock save/restore hooks when setting up Xen's PV clock. It aims to clarify that these common hooks are not used when running as a Xen guest. > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > index 3d3165eef8214..21d366d01985e 100644 > --- a/arch/x86/xen/time.c > +++ b/arch/x86/xen/time.c > @@ -568,6 +568,12 @@ static void __init xen_init_time_common(void) > xen_sched_clock_offset =3D xen_clocksource_read(); > static_call_update(pv_steal_clock, xen_steal_clock); > paravirt_set_sched_clock(xen_sched_clock); > + /* > + * Xen has paravirtualized suspend/resume and so doesn't use the common > + * x86 sched_clock save/restore hooks. > + */ > + x86_platform.save_sched_clock_state =3D NULL; > + x86_platform.restore_sched_clock_state =3D NULL; Does setting these hooks to NULL lead to an unconditional pointer dereferen= ce regression during suspend, hibernation, or kexec operations in Xen guests? Looking at save_processor_state() and __restore_processor_state() in arch/x86/power/cpu.c, the hooks are called directly without being checked for NULL first: arch/x86/power/cpu.c:save_processor_state() { __save_processor_state(&saved_context); x86_platform.save_sched_clock_state(); } arch/x86/power/cpu.c:__restore_processor_state() { ... do_fpu_end(); tsc_verify_tsc_adjust(true); x86_platform.restore_sched_clock_state(); ... } Will operations that trigger a generic CPU state save or restore on a Xen guest execute a call on these NULL pointers, causing a kernel panic regression? Should these instead be assigned to an empty stub function to safely bypass them? > =20 > tsc_register_calibration_routines(xen_tsc_khz, NULL); > x86_platform.get_wallclock =3D xen_get_wallclock; --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260515191942.1892= 718-1-seanjc@google.com?part=3D15