From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Sent: Wednesday, May 12, 2021 1:47 AM > > Mohammed reports (https://bugzilla.kernel.org/show_bug.cgi?id=213029) > the commit e4ab4658f1cf ("clocksource/drivers/hyper-v: Handle vDSO > differences inline") broke vDSO on x86. The problem appears to be that > VDSO_CLOCKMODE_HVCLOCK is an enum value in 'enum vdso_clock_mode' and > '#ifdef VDSO_CLOCKMODE_HVCLOCK' branch evaluates to false (it is not > a define). Replace it with CONFIG_X86 as it is the only arch which > has this mode currently. > > Reported-by: Mohammed Gamal <mgamal@xxxxxxxxxx> > Fixes: e4ab4658f1cf ("clocksource/drivers/hyper-v: Handle vDSO differences inline") > Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > --- > drivers/clocksource/hyperv_timer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c > index 977fd05ac35f..e17421f5e47d 100644 > --- a/drivers/clocksource/hyperv_timer.c > +++ b/drivers/clocksource/hyperv_timer.c > @@ -419,7 +419,7 @@ static void resume_hv_clock_tsc(struct clocksource *arg) > hv_set_register(HV_REGISTER_REFERENCE_TSC, tsc_msr); > } > > -#ifdef VDSO_CLOCKMODE_HVCLOCK > +#ifdef CONFIG_X86 > static int hv_cs_enable(struct clocksource *cs) > { > vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK); > @@ -435,7 +435,7 @@ static struct clocksource hyperv_cs_tsc = { > .flags = CLOCK_SOURCE_IS_CONTINUOUS, > .suspend= suspend_hv_clock_tsc, > .resume = resume_hv_clock_tsc, > -#ifdef VDSO_CLOCKMODE_HVCLOCK > +#ifdef CONFIG_X86 > .enable = hv_cs_enable, > .vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK, > #else > -- > 2.31.1 Well, bummer. I thought I was being so clever. I hate having to base the behavior directly on the architecture instead of the actual VDSO feature, but I don't see a way to detect whether VDSO_CLOCKMODE_HVCLOCK is defined or not. The other alternative would be to add another #define such as VDSO_CLOCKMODE_HVCLOCK_PRESENT in arch/x86/include/asm/vdso/clocksource.h, and use it in the #ifdefs here. But that's a bit messy too, and I'm not sure it's worth the trouble. So, Reviewed-by: Michael Kelley <mikelley@xxxxxxxxxxxxx> Mohammed -- Thanks for finding this!
