Re: [Xenomai-core] local_irq_save/local_irq_restore in real-time interrupt handler and slab corruption.

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix wrote:
> Hi,
> 
> I am chasing a slab corruption bug which happens on a Xenomai+RTnet
> enabled box under heavy non real-time network load (which passes
> through rtnet and rtmac_vnic to Linux which does NAT and resend it to
> another rtmac_vnic). When reading some I-pipe tracer traces, I
> remarked that I forgot to replace a local_irq_save/local_irq_restore
> with local_irq_save_hw/local_irq_restore_hw in a real-time interrupt
> handler. I fixed this bug, and the slab corruption seems to be gone.

Hope you mean rtdm_lock_irqsave/irqrestore instead. Otherwise Xenomai's
domain state would not be updated appropriately - which is at least unclean.

BTW, CONFIG_IPIPE_DEBUG_CONTEXT should have caught this bug as well.

> 
> So, my question is: is it possible ? I mean, if local_irq_restore in
> the real-time interrupt handler calls __ipipe_sync_stage, the root
> domain is not stalled, so there should be no problem Linux-wise
> playing root domain interrupts, I would rather expect the I-pipe state
> to be jammed (after all, we are probably reentering functions that
> should not be reentered), not Linux state.

If I grab it correctly ATM, __ipipe_sync_stage() does not check for the
domain stall bits, it assumes the caller has done so. Thus,

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux