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] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR21MB16883A65BBCFA19A30BADA4CD7749@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Thu, 11 May 2023 23:11:07 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Peter Zijlstra <peterz@...radead.org>, Wei Liu <wei.liu@...nel.org>
CC:     "ltykernel@...il.com" <ltykernel@...il.com>,
        "bigeasy@...utronix.de" <bigeasy@...utronix.de>,
        Mark Rutland <Mark.Rutland@....com>,
        "maz@...nel.org" <maz@...nel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
        "kernel@...0n.name" <kernel@...0n.name>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
        "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "jgross@...e.com" <jgross@...e.com>,
        "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Dexuan Cui <decui@...rosoft.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "longman@...hat.com" <longman@...hat.com>,
        "boqun.feng@...il.com" <boqun.feng@...il.com>,
        "pmladek@...e.com" <pmladek@...e.com>,
        "senozhatsky@...omium.org" <senozhatsky@...omium.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "john.ogness@...utronix.de" <john.ogness@...utronix.de>,
        "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
        "bsegall@...gle.com" <bsegall@...gle.com>,
        "mgorman@...e.de" <mgorman@...e.de>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "vschneid@...hat.com" <vschneid@...hat.com>,
        "jstultz@...gle.com" <jstultz@...gle.com>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: RE: [RFC][PATCH 7/9] x86/tsc: Provide sched_clock_noinstr()

From: Peter Zijlstra <peterz@...radead.org> Sent: Thursday, May 11, 2023 1:24 PM
> 
> On Mon, May 08, 2023 at 11:30:43PM +0000, Wei Liu wrote:
> > On Mon, May 08, 2023 at 11:44:19PM +0200, Peter Zijlstra wrote:
> > > On Mon, May 08, 2023 at 11:19:58PM +0200, Peter Zijlstra wrote:
> > >
> > > > --- a/drivers/clocksource/hyperv_timer.c
> > > > +++ b/drivers/clocksource/hyperv_timer.c
> > > > @@ -408,9 +408,9 @@ static u64 notrace read_hv_clock_tsc_cs(
> > > >  	return read_hv_clock_tsc();
> > > >  }
> > > >
> > > > -static u64 notrace read_hv_sched_clock_tsc(void)
> > > > +static u64 noinstr read_hv_sched_clock_tsc(void)
> > > >  {
> > > > -	return (read_hv_clock_tsc() - hv_sched_clock_offset) *
> > > > +	return (hv_read_tsc_page(hv_get_tsc_page()) - hv_sched_clock_offset) *
> > > >  		(NSEC_PER_SEC / HV_CLOCK_HZ);
> > > >  }
> > > >
> > > > --- a/include/clocksource/hyperv_timer.h
> > > > +++ b/include/clocksource/hyperv_timer.h
> > > > @@ -38,7 +38,7 @@ extern void hv_remap_tsc_clocksource(voi
> > > >  extern unsigned long hv_get_tsc_pfn(void);
> > > >  extern struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
> > > >
> > > > -static inline notrace u64
> > > > +static __always_inline notrace u64
> > > >  hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg, u64 *cur_tsc)
> > > >  {
> > > >  	u64 scale, offset;
> > > > @@ -85,7 +85,7 @@ hv_read_tsc_page_tsc(const struct ms_hyp
> > > >  	return mul_u64_u64_shr(*cur_tsc, scale, 64) + offset;
> > > >  }
> > > >
> > > > -static inline notrace u64
> > > > +static __always_inline notrace u64
> > > >  hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
> > > >  {
> > > >  	u64 cur_tsc;
> > >
> > > Hyper-V folks!
> > >
> > > While reviewing all this I found the following 'gem':
> > >
> > > hv_init_clocksource()
> > >   hv_setup_sched_clock()
> > >     paravirt_set_sched_clock(read_hv_sched_clock_msr)
> > >
> > > read_hv_sched_clock_msr() [notrace]
> > >   read_hv_clock_msr()     [notrace]
> > >     hv_get_register()      *traced*
> > >       hv_get_non_nested_register() ...
> > >         hv_ghcb_msr_read()
> > > 	  WARN_ON(in_nmi())
> > > 	  ...
> > > 	  local_irq_save()
> > >
> > >
> > > Note that:
> > >
> > >  a) sched_clock() is used in NMI context a *LOT*
> > >  b) sched_clock() is notrace (or even noinstr with these patches)
> > >     and local_irq_save() implies tracing
> > >
> >
> > Tianyu and Michael, what's your thought on this?
> >
> > Is the MSR-based GHCB usable at this point?
> >
> > What other clock source can be used?
> 
> You do have TSC support -- which is what I fixed for you. It's just the
> whole MSR thing that is comically broken.
> 
> You could do a read_hv_clock_msr() implementation using
> __rdmsr() and add some sanity checking that anything GHCB using (SEV?)
> *will* use TSC.
> 
> Anyway, will you guys do that, or should I pull out the chainsaw and fix
> it for you?

Peter -- I'll work on a fix.  But it will be the first half of next week before
I can do it.

Michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ