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: da...@l8s.co.uk