Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] Setting `x86_platform.save_sched_clock_state` and `restore_sched_clock_state` to NULL for PV clocksources causes a fatal kernel panic on S3/S4 suspend and resume. --
commit 4d4877d2e739eb2258c919e41775916ae05af732 Author: Sean Christopherson <[email protected]> x86/tsc: WARN if TSC sched_clock save/restore used with PV sched_clock This commit adds a warning to guard against regressions when the default TSC sched_clock save and restore hooks are called while using a PV sched_clock. > Now that all PV clocksources override the sched_clock save/restore hooks > when overriding sched_clock, WARN if the "default" TSC hooks are invoked > when using a PV sched_clock, e.g. to guard against regressions. Earlier patches in this series appear to override these hooks by setting them to NULL, such as setting x86_platform.save_sched_clock_state = NULL. Could this lead to a panic during suspend and resume? Looking at the callers in arch/x86/power/cpu.c, save_processor_state() and restore_processor_state() unconditionally invoke these function pointers without checking for NULL: void save_processor_state(void) { __save_processor_state(&saved_context); x86_platform.save_sched_clock_state(); } When VMware or Xen HVM guests attempt to suspend or hibernate, won't the kernel execute the NULL pointer and crash? Would it be better for PV clocksources to override the hooks to a safe no-op function like x86_init_noop rather than NULL, or for the callers in power/cpu.c to explicitly check for NULL before invocation? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=17
