> The root cause of this bug lies in the fact that the XICS interrupt controller > uses a radix tree for its reverse irq mapping and that we cannot allocate the tree > nodes (even GFP_ATOMIC) with preemption disabled. Is that yet another caes of -rt changing some basic kernel semantics ? > In fact, we have 2 nested preemption disabling when we want to allocate > a new node: > > - setup_irq() does a spin_lock_irqsave() before calling xics_startup() which > then calls irq_radix_revmap() to insert a new node in the tree > > - irq_radix_revmap() also does a spin_lock_irqsave() (in irq_radix_wrlock()) > before the radix_tree_insert() > > The first patch moves the call to irq_radix_revmap() from xics_startup() out to > xics_host_map_direct() and xics_host_map_lpar() which are called with preemption > enabled. I suppose that would work. > The second patch is a little more involved in that it takes advantage of > the concurrent radix tree to simplify the locking requirements and allows > to allocate a new node outside a preemption disabled section. > > I just hope I've correctly understood the concurrent radix trees semantic > and got the (absence of) locking right. Hrm, that will need some scrutinity. Thanks for looking at this. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
