ACK: [Maverick][SRU] More fallout from 2.6.35.14 update

[Stefan Bader]

On 03.12.2011 01:55, Herton R. Krzesinski wrote:
> After one report and some automated digging I did, I came up detecting
> more problems in 2.6.35.14 update. This is an attempt to avoid
> regressions after applying it, before we hit bug reports.
> 
> This series contains patches which fixes referenced problems in some of
> the commits present in 2.6.35.14
> 
> With the exception of the two reverts, all of them are already upstream
> patches sent to stable at some point, even those without Cc: stable in
> its original changelog:
> 
> * (pre-stable) x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message
> has Cc: stable (with a typo), reported by Julian Wiedmann on the
> 2.6.35.14 tracking bug, fixes a bug introduced by "x86, intel, power:
> Initialize MSR_IA32_ENERGY_PERF_BIAS" in the stable update
> 
> * (pre-stable) mm: Fix fixup_user_fault() for MMU=n
> As far as I know we don't have any kernel which have CONFIG_MMU=n set,
> this fixes a regression with CONFIG_MMU=n
> So it's optional to take this one. Doesn't have Cc: stable, but stable
> grabbed it and applied on 3.0.2 for example.
> 
> * (pre-stable) USB: serial: pl2303: rm duplicate id
> This fixes a regression, Cc: stable
> 
> I Added pre-stable to these patches, but I don't know if they will come
> through another 2.6.35 update, or if we will have another 2.6.35 update.
> I guess these, if applied, will not require verification, since they are
> stable material?
> 
> Besides them, I added two reverts related to a single regression,
> instead of backporting a fix upstream:
> Revert "xen: Use IRQF_FORCE_RESUME"
> Revert "genirq: Add IRQF_FORCE_RESUME"
> For the reverted patches, which introduces a regression
> (http://bugs.launchpad.net/bugs/898139), I did not apply the upstream
> fix "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier".
> I chose to revert them, because the upstream fix didn't apply cleanly,
> it seems to require a similar backport as already applied on 2.6.32
> stable series, but I didn't want to take a risky approach (the backport
> isn't straightforward it seems), so I reverted them. May be Stefan wants
> to take a look at this one.
> 
> Also since these are just related to the 2.6.35.14 update, not an SRU
> per se, the BugLinks on them point to the 2.6.35.14 tracking bug. Should
> a new bug be opened with an SRU Justification, or is this ok?
> 

I checked that Maverick contains the important fix from 2.6.37
* xen: events: do not unmask event channels on resume
The other patches look ok to me and the two reverts will be fine and need no
follow-up as long as there is no 2.6.35.y release causing dependency issues.

-Stefan