Re: CVS commit: src/sys/arch/xen/xen

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Dec 03, 2013 at 08:51:00PM +0000, Manuel Bouyer wrote:
> Module Name:  src
> Committed By: bouyer
> Date:         Tue Dec  3 20:51:00 UTC 2013
> 
> Modified Files:
>       src/sys/arch/xen/xen: evtchn.c
> 
> Log Message:
> Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" printf.
> With help from Robert Elz we've finally figured out what's going on, and
> it actually isn't a bug in the handler, but related to spin mutexes.
> When a spin mutex is released, the IPL isn't lowered back if the
> curcpu is holding other spin mutexes. This is because mutexes may not
> be released in order (and, in this case, the CPU in interrupted while
> it holds a spin mutex at IPL < IPL_SCHED).

Hmmm... that can lead to unexpected long periods with interrupts disabled.
Or, more likely, high priority interrupts being disabled for longer than
expected - because spin locks aren't normally used unless some interrupt
need to be disabled and are rarely held for long.

Saving the old spl in the mutex always seems like a good idea - until
you start needing to do lock chaining.
And if you bad lock chaining there are bigger problems.

I guess it is nothing like as bad as systems that try to avoid priority
inversion problems by raising the priority of a thread that holds a
sleep lock when a higher priority thread waits for it - and then only
drop the priority when the thread holds no locks.
That can cause serious problems because low priority threads can
quite reasonably hold sleep locks (that are contended by other similar
processes) for very long periods.

        David

-- 
David Laight: david%l8s.co.uk@localhost