[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.

IIRC, the story here was that the actual fix was another patch before (I check
to make sure that is in Maverick). But the Xen folks felt the approach to have
flags in generic IRQ code was cleaner. Unfortunately this did not work as
expected. The upstream fix needs some PM code rework (which I am not sure
Maverick has or not).
Long story short, if the real fix is in there, I would rather leave those two
reverted patches out. Even more as there does not seem to be much longterm work
going on, so the chance that we need them because other things build on top is less.

-Stefan
> 
> 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?
>