Re: [34-longterm 074/179] xen: Use IRQF_FORCE_RESUME

[Paul Gortmaker <paul.gortmaker@windriver.com>]

[Re: [34-longterm 074/179] xen: Use IRQF_FORCE_RESUME] On 15/05/2012 (Tue 00:02) Jonathan Nieder wrote:

> Hi Paul,
> 
> Paul Gortmaker wrote:
> 
> > From: Thomas Gleixner <tglx@linutronix.de>
> [...]
> >     If you see a problem with using this for longterm, please comment.
> [...]
> > commit 676dc3cf5bc36a9e129a3ad8fe3bd7b2ebf20f5d upstream.
> >
> > Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
> > walk through the interrupt descriptors.
> 
> This produces resume failures and migration failures in Xen guests[1].
> 
> Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such
> IRQs earlier, 2011-11-09) is needed on top to avoid regressions.
> 
> Hope that helps,
> Jonathan
> 
> [1] http://thread.gmane.org/gmane.linux.kernel/1198673

Hi Jonathan,

I'd considered this patch, but then saw Greg used it on 2.6.32
and reverted it one release later:

-------------------
commit 758d61b4a76e6ad4224780771edbc6d3a0c29b16
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Tue Nov 8 15:40:42 2011 -0800

    Revert "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier"
    
    This reverts commit 0f12a6ad9fa3a03f2bcee36c9cb704821e244c40.
    
    It causes too many build errors and needs to be done properly.
    
    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Cc: Ian Campbell <ian.campbell@citrix.com>
 [...]
-------------

What I didn't realize was that it got re-added as a v2 again in:

-------------
commit 5e87d8ee34e32fda720f3a4e4055f570b09230d6
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 9 08:53:09 2011 +0000

    genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
    
[...]

    Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
    resume function directly from sysdev_resume).
    
    v2: Fixed non-x86 build errors.
-----------

I'll make sure the v2 ends up in the 34 queue.

Thanks again,
Paul.