[Lucid][pull request] Update to 2.6.32.12 stable kernel
Andy Whitcroft
apw at canonical.com
Fri May 28 08:28:35 UTC 2010
On Fri, May 28, 2010 at 10:04:23AM +0200, Stefan Bader wrote:
> On 05/27/2010 10:49 AM, Stefan Bader wrote:
> > 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
> >
>
> Mail from Matthieu suggests all three patches of that series should not be in
> .32, which would also require this to not be applied:
>
> commit b6b3dcd55e2327a968833ff3f22eda3b8dd7ef9e
> Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> Date: Tue Apr 20 10:33:50 2010 -0400
>
> lockdep: fix incorrect percpu usage
>
> The main problem with those patches seems to be with ia64 which has not yet been
> converted to dynamic percpu variables. So, while this one is unlike the other
> two and not converts a per_cpu_offset to a per_cpu_ptr, it likely will be
> removed in the next stable tree.
As they are very likely going to be reverted we should be reverting them
too. If we find out in advance all and well. But I suspect holding
these three back (not putting them in) is the prudent path.
-apw
More information about the kernel-team
mailing list