[Lucid][pull request] Update to 2.6.32.12 stable kernel

[Stefan Bader]

On 05/06/2010 02:32 PM, Stefan Bader wrote:
> commit ea0a09acd81c6d52c77d80f0d4089795df7bcb58
> Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> 
>     modules: fix incorrect percpu usage
> 
> # Type: Cleanup
> # Looks ok
> 
> commit d150a2b96558a7349cbf3a72a279c37bc67d50fb
> Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> 
>     module: fix __module_ref_addr()
> 
> # Type: Cleanup
> ! Though this looks like the previous things, there have been problems wit
> ! ia64 and it has been asked to drop this in future releases.
> 

The second patch has been reverted in 2.6.32.14 now and the following stable
mail looks like we might want to skip the first one, too.

> These commits included in 2.6.32.12:
> 
> ea0a09acd81c6d52c77d80f0d4089795df7bcb58 "modules: fix incorrect percpu usage"
> d150a2b96558a7349cbf3a72a279c37bc67d50fb "module: fix __module_ref_addr()"
> 
> apparently caused regressions, and have been reverted in SLE 11.1 and
> Debian unstable.
> 
> The second has also now been reverted in 2.6.32.14, but the first has
> not.  I'm afraid I don't understand the problems they were trying to
> solve, or the problems they caused, so could someone explain why the
> first should or not should not be reverted in 2.6.32-stable?
> 
> (Matthieu previously asked whether it was really correct for 2.6.32:
> http://linux.kernel.org/pipermail/stable-review/2010-April/003571.html )
> 
> Ben.
> 
> -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. 

Actually both change the use of a per_cpu_offset() into per_cpu_ptr() and if its
wrong in the second case it should be wrong in both. Suggesting to not apply the
first one. Thoughts?

-Stefan