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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2015-10-08 at 16:20 +0100, Andrew Cooper wrote:
> On 08/10/15 15:58, George Dunlap wrote:

> > Generic scheduling code is called from interrupt contexts --
> > namely,
> > vcpu_wake()
> 
> There are a lot of codepaths, but I cant see one which is definitely
> called with interrupts disables.  (OTOH, I can see several where
> interrupts are definitely enabled).
> 
Sorry, it's certainly me, but I don't think I understand this.

AFAICT, you are saying that you fail to find in the code, situations
the scheduler code is invoked, with interrupts already disabled, is
this correct? In particular "definitely called with interrupt disabled"
is what confuses me... :-/

Also (assuming what I just said is what you meant), are you referring
"just" to schedule(), or even to other scheduler's code, which also
disables interrupt when taking the lock(s) it needs, like, e.g.,
vcpu_wake() as George said?

> > , which for the credit scheduler wants to put things on the
> > runqueue.  Lock taken in interrupt context => interrupts must be
> > disabled whenever taking the lock, yes?
> 
> Correct, which is the purpose of the ASSERT()s in the _irq() and
> _irqsave() variants.
> 
What ASSERT()? I don't find any assert in _spin_lock_irqsave() (which
thing makes sense to me):

unsigned long _spin_lock_irqsave(spinlock_t *lock)
{
    unsigned long flags;

    local_irq_save(flags);
    _spin_lock(lock);
    return flags;
}

Note that, again, I'm not just being nitpicking, for the sake of it...
I'm trying to understand, as I'm interesting in trying making things
better. :-)

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