Xen devel - Dec 2009 - [PATCH] xen: don''t leak IRQs over suspend/resume.

On resume irq_info[*].evtchn is reset to 0 since event channel mappings are not
preserved over suspend/resume. The other contents of irq_info is preserved to
allow rebind_evtchn_irq() to function.

However when a device resumes it will try to unbind from the previous IRQ (e.g.
blkfront goes blkfront_resume() -> blkif_free() ->
unbind_from_irqhandler() ->
unbind_from_irq()). This will fail due to the check for VALID_EVTCHN in
unbind_from_irq() and the IRQ is leaked. The device will then continue to
resume and allocate a new IRQ, eventually leading to find_unbound_irq()
panic()ing.

Fix this by changing unbind_from_irq() to handle teardown of interrupts which
have type!=IRQT_UNBOUND but are not currently bound to a specific event
channel.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index adc8c09..951f993 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -888,6 +888,9 @@ static void unbind_from_irq(unsigned int irq)
 		bind_evtchn_to_cpu(evtchn, 0);
 
 		evtchn_to_irq[evtchn] = -1;
+	}
+
+	if (irq_info[irq].type != IRQT_UNBOUND) {
 		irq_info[irq] = mk_unbound_info();
 
 		dynamic_irq_cleanup(irq);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Ian Campbell <ian.campbell@citrix.com> 01.12.09 17:15
>>>
>On resume irq_info[*].evtchn is reset to 0 since event channel mappings are
not
>preserved over suspend/resume. The other contents of irq_info is preserved
to
>allow rebind_evtchn_irq() to function.
>
>However when a device resumes it will try to unbind from the previous IRQ
(e.g.
>blkfront goes blkfront_resume() -> blkif_free() ->
unbind_from_irqhandler() ->
>unbind_from_irq()). This will fail due to the check for VALID_EVTCHN in
>unbind_from_irq() and the IRQ is leaked. The device will then continue to
>resume and allocate a new IRQ, eventually leading to find_unbound_irq()
>panic()ing.
>
>Fix this by changing unbind_from_irq() to handle teardown of interrupts
which
>have type!=IRQT_UNBOUND but are not currently bound to a specific event
>channel.
This seems applicable to the 2.6.18/.27 trees too, doesn''t it?

Jan 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 02/12/2009 08:47, "Jan Beulich" <JBeulich@novell.com> wrote:
>> Fix this by changing unbind_from_irq() to handle teardown of interrupts
which
>> have type!=IRQT_UNBOUND but are not currently bound to a specific event
>> channel.
> 
> This seems applicable to the 2.6.18/.27 trees too, doesn''t it?
Pv_ops'' IRQ/evtchn handling is quite different from .18/27''s.
The latter
don''t have this issue -- we''d have noticed long ago if they
did!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <keir.fraser@eu.citrix.com> 02.12.09 10:01
>>>
>On 02/12/2009 08:47, "Jan Beulich" <JBeulich@novell.com>
wrote:
>
>>> Fix this by changing unbind_from_irq() to handle teardown of
interrupts which
>>> have type!=IRQT_UNBOUND but are not currently bound to a specific
event
>>> channel.
>> 
>> This seems applicable to the 2.6.18/.27 trees too, doesn''t it?
>
>Pv_ops'' IRQ/evtchn handling is quite different from
.18/27''s. The latter
>don''t have this issue -- we''d have noticed long ago if
they did!
Oh, right, find_unbound_irq() in these trees doesn''t look at the IRQ
type, but at irq_bindcount[], which is being updated in
unbind_from_irq() regardless of the event channel association.

Sorry for the noise,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel