On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> >> And when looking at the holders of rpilock, I think one issue could be
> >> that we hold that lock while calling into xnpod_renice_root [1], ie.
> >> doing a potential context switch. Was this checked to be save?
> > 
> > xnpod_renice_root() does no reschedule immediately on purpose, we would
> > never have been able to run any SMP config more than a couple of seconds
> > otherwise. (See the NOSWITCH bit).
> OK, then it's not the cause.
> > 
> >> Furthermore, that code path reveals that we take nklock nested into
> >> rpilock [2]. I haven't found a spot for the other way around (and I hope
> >> there is none)
> > 
> > xnshadow_start().
> Nope, that one is not holding nklock.

Indeed, but this only works because its callers who may hold this lock
do not activate shadow threads so far. This looks so fragile... I'll add
some comment about this in the doc.

> But I found an offender...
> > 
> >> , but such nesting is already evil per se...
> > 
> > Well, nesting spinlocks only falls into evilness when you get a circular
> > graph, but since the rpilock is a rookie in the locking team, I'm going
> > to check this.
> Take this one: gatekeeper_thread calls into rpi_pop with nklock
> acquired. So we have a classic ABAB locking bug. Bang!


The fix needs some thought and attention, we are running against the
deletion path here.

PS: Time to switch to -core.

> Jan

Xenomai-core mailing list

Reply via email to