[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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |