Re: [Xen-devel] Hypervisor memory leak/corruption because of guest irqs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.09.12 at 21:08, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> Its not completely trivial to turn it into a discriminated union (in an
> acceptable way), as irq_desc and irqaction is common while
> irq_guest_action_t is x86 specific (and irq.c private, currently),
> meaning the introduction of an arch_irqaction.
> 
> Now that the two actions are different, you could perhaps convert
> __do_IRQ_guest() to be the 'handler' of the irqaction, which appears to
> cause large amounts of "if(desc->status & IRQ_GUEST) then do something"
> code to fall out.  Continuing along this line leads to large amounts of
> code change.
> 
> I will see about working on a bare minimum patch to make the teardown of
> guest IRQs safe, but I dont think it will be very small, and it will
> open the way for some cleanup.

Is there any reason why simply tying the removal of the timer
to the clearing of IRQ_GUEST isn't possible? This is basically
already the case for __pirq_guest_unbind() (where the caller
takes care of correctly dealing with the returned action pointer).

Hence if dynamic_irq_cleanup() indeed can be reached with the
flag still set, it would seem quite obvious that this simply needs
adding similar treatment. But I would have expected that the
unbind path should be taken in any case (and destroy_irq()
only be used for subsequent, final cleanup) - is there perhaps
a problem in when the forced unbind happens?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel