Re: [Xen-devel] [PATCH] xen/sched: fix locking in sched_tick_[suspend|resume]()

From: Dario Faggioli <dfaggioli@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	 xen-devel@lists.xenproject.org
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/sched: fix locking in sched_tick_[suspend|resume]()
Date: Fri, 04 Oct 2019 16:29:25 +0200	[thread overview]
Message-ID: <e4a931227e71071a8ae3ab853a1f861d0d295e16.camel@suse.com> (raw)
In-Reply-To: <7cc89db1-90de-8435-77f3-c69e6e0217e4@citrix.com>


[-- Attachment #1.1: Type: text/plain, Size: 2557 bytes --]

On Fri, 2019-10-04 at 08:50 +0100, Andrew Cooper wrote:
> On 04/10/2019 07:40, Juergen Gross wrote:
> > sched_tick_suspend() and sched_tick_resume() should not call the
> > scheduler specific timer handlers in case the cpu they are running
> > on
> > is just being moved to or from a cpupool.
> > 
> > Use a new percpu lock for that purpose.
> > 
> > Reported-by: Sergey Dyasli <sergey.dyasli@citrix.com>
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> > ---
> > To be applied on top of my core scheduling series.
> 
> There is a somewhat interesting stack trace to go with this
> 
Sorry, I don't think I get this. Does it mean that you see the
stacktrace below _even_with_ the patch applied?

> (XEN) Testing NMI watchdog on all CPUs: ok
> (XEN) ----[ Xen-4.13.0-8.0.12-d  x86_64  debug=y   Not tainted ]----
> (XEN) CPU:    79
> (XEN) RIP:    e008:[<ffff82d0802467dc>] set_timer+0x39/0x1f7
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
> <snip>
> (XEN) Xen call trace:
> (XEN)    [<ffff82d0802467dc>] set_timer+0x39/0x1f7
> (XEN)    [<ffff82d08022c1f4>]
> sched_credit.c#csched_tick_resume+0x54/0x59
> (XEN)    [<ffff82d080241dfe>] sched_tick_resume+0x67/0x86
> (XEN)    [<ffff82d0802eda52>] mwait-idle.c#mwait_idle+0x32b/0x357
> (XEN)    [<ffff82d08027939e>] domain.c#idle_loop+0xa6/0xc2
> (XEN)
> (XEN) Running stub recovery selftests...
> (XEN) Pagetable walk from 0000000000000048:
> (XEN) traps.c:1564: GPF (0000): ffff82d0bffff041 [ffff82d0bffff041]
> ->
> ffff82d0803893f2
> (XEN)  L4[0x000] = 00000082cfb9c063 ffffffffffffffff
> (XEN) traps.c:759: Trap 12: ffff82d0bffff040 [ffff82d0bffff040] ->
> ffff82d0803893f2
> (XEN)  L3[0x000] = 00000082cfb9b063 ffffffffffffffff
> (XEN) traps.c:1098: Trap 3: ffff82d0bffff041 [ffff82d0bffff041] ->
> ffff82d0803893f2
> (XEN)  L2[0x000] = 00000082cfb9a063 ffffffffffffffff
> (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 79:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 0000000000000048
> (XEN) ****************************************
> 
> which demonstrates CPU 79 exploding straight out of idle, while the
> BSP
> is continuing to boot.
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel