linux-kernel - RE: [PATCH v2 1/1] x86/hyperv: Initialize clockevents earlier in CPU onlining

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CY4PR21MB062904EB8E4B90192E893750D74D0@CY4PR21MB0629.namprd21.prod.outlook.com>
Date:   Mon, 18 Nov 2019 01:23:15 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Dexuan Cui <decui@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        vkuznets <vkuznets@...hat.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "sashal@...nel.org" <sashal@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>, "hpa@...or.com" <hpa@...or.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "will@...nel.org" <will@...nel.org>,
        "Ganapatrao.Kulkarni@...ium.com" <Ganapatrao.Kulkarni@...ium.com>,
        "james.morse@....com" <james.morse@....com>,
        "steven.price@....com" <steven.price@....com>,
        "josephl@...dia.com" <josephl@...dia.com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>
Subject: RE: [PATCH v2 1/1] x86/hyperv: Initialize clockevents earlier in CPU
 onlining

From: Dexuan Cui <decui@...rosoft.com>  Sent: Thursday, November 14, 2019 10:49 PM
> > From: Michael Kelley <mikelley@...rosoft.com>
> > Sent: Tuesday, November 12, 2019 5:12 PM
> > ...
> > @@ -190,14 +278,20 @@ void hv_stimer_free(void)
> >  void hv_stimer_global_cleanup(void)
> >  {
> >  	int	cpu;
> >  ...
> > +	/*
> > +	 * hv_stime_legacy_cleanup() will stop the stimer if Direct
> > +	 * Mode is not enabled, and fallback to the LAPIC timer.
> > +	 */
> > +	for_each_present_cpu(cpu) {
> > +		hv_stimer_legacy_cleanup(cpu);
> >  	}
> > +
> > +	/*
> > +	 * If Direct Mode is enabled, the cpuhp teardown callback
> > +	 * (hv_stimer_cleanup) will be run on all CPUs to stop the
> > +	 * stimers.
> > +	 */
> >  	hv_stimer_free();
> >  }
> 
> In the case of direct_mode_enabled == true: When hv_vmbus unloads,
> vmbus_exit() -> hv_stimer_global_cleanup() -> hv_stimer_free() ->
> cpuhp_remove_state() disables the direct mode timers.
> 
> This does not look symmetric since hv_stimer_alloc() is called before
> hv_vmbus loads, but I suppose this is not a real issue because hv_vmbus
> should never unload in practice. :-)

Thanks for the review.  Looking at this a bit more, ideally
hv_stimer_global_cleanup() should go away entirely.  vmbus_exit() should
let the call to cpuhp_remove_state() clean up the stimer on each CPU via 
hv_synic_cleanup().   But vmbus_exit() shuts down the VMbus first, which
is really the wrong order.

As you say, vmbus_exit() never gets called in practice, so it's not a
current issue.  But I'll look at fixing this in a future patch so that it
makes logical sense.

Michael

> 
> Tested-by: Dexuan Cui <decui@...rosoft.com>
> Reviewed-by: Dexuan Cui <decui@...rosoft.com>