[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/9] xen: sched: make locking for {insert, remove}_vcpu consistent



On Tue, 2015-09-29 at 23:40 +0200, Dario Faggioli wrote:
> On Tue, 2015-09-29 at 18:31 +0100, Andrew Cooper wrote:
> > On 29/09/15 17:55, Dario Faggioli wrote:

> > Is the use of _lock_irq() here to cover another issue expecting
> > interrupts to be disabled, or could it be replaced with a plain
> > spin_lock()?
> > 
> As said, it is probably the case that spin_lock() would be ok, here
> as
> well as elsewhere. This is being done like this in this patch for
> consistency, as that is what happens **everywhere** else in
> scheduling
> code. In fact, I haven't tried, but it may well be the case that,
> converting only one (or a subset) of locks to non _irq* variants,
> we'd
> make check_lock() complain.
> 
And now I have just checked, and that indeed looks to be the case.

I.e., I changed the spin_lock_irq() being touched in this patch to
spin_lock(), and here's what I see (very early, during Xen's boot):

(XEN) Xen BUG at spinlock.c:48
(XEN) ----[ Xen-4.7-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d08012df6e>] check_lock+0x3d/0x41
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff82d08033cd68   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: 0000000000000001   rdi: ffff82d08033cd70
(XEN) rbp: ffff8300dbaf7e40   rsp: ffff8300dbaf7e40   r8:  0000000000000001
(XEN) r9:  0000000000000001   r10: 0000000000000001   r11: 0000000000000004
(XEN) r12: ffff82d0803272a0   r13: ffff83031fa29000   r14: ffff82d08033cd60
(XEN) r15: ffff82d08033cd68   cr0: 000000008005003b   cr4: 00000000000026e0
(XEN) cr3: 00000000dbaa3000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff8300dbaf7e40:
(XEN)    ffff8300dbaf7e58 ffff82d08012df9d 0000000000000282 ffff8300dbaf7e70
(XEN)    ffff82d08012e000 ffff8300db8f4000 ffff8300dbaf7ec0 ffff82d08012b6e3
(XEN)    ffff82d080189be6 ffff8300dbaf7eb8 ffff82d08018a008 ffff8300db8f4000
(XEN)    ffff8300dbaf7f18 ffff83031fa29000 0000000000000001 ffff82d080291d20
(XEN)    ffff8300dbaf7ee0 ffff82d08010642e 00000000000002f8 ffff8300dbaf0000
(XEN)    ffff8300dbaf7ef0 ffff82d080106579 ffff8300dbaf7f10 ffff82d0801895b2
(XEN)    ffff8300dbaf0000 ffff8300dbaf7f18 ffff8300dbaf7fb8 0080026200000002
(XEN)    0000000000000000 00000000000dbaf6 ffff8300dbaf6000 ffff8300dbaf0000
(XEN)    ffff8300dbaf0000 ffff8300dbaf7f18 ffff83031fa29000 0000000000000001
(XEN)    ffff82d080291d20 ffff8300dbaf7f78 ffff82d080184130 ffff8300dbaf7f88
(XEN)    ffff82d08018546a ffff8300dbaf7f98 ffff82d080185491 ffff8300dbaf7fb8
(XEN)    ffff82d0802c763f ffff82d0802e66c0 ffff83031fabb610 ffff82d0802f7f08
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffff8300dbb3f000 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82d08012df6e>] check_lock+0x3d/0x41
(XEN)    [<ffff82d08012df9d>] _spin_lock+0x11/0x52
(XEN)    [<ffff82d08012e000>] _spin_lock_irqsave+0xd/0x13
(XEN)    [<ffff82d08012b6e3>] vcpu_wake+0x36/0x3ce
(XEN)    [<ffff82d08010642e>] domain_unpause+0x38/0x48
(XEN)    [<ffff82d080106579>] domain_unpause_by_systemcontroller+0x2c/0x3b
(XEN)    [<ffff82d0801895b2>] init_done+0x1d/0x144
(XEN) 
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at spinlock.c:48
(XEN) ****************************************

So, really, (trying to)do the spinlock conversion in its dedicated
series is the way to go, IMO.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.