[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.6.32-stable percpu fixes



* Ben Hutchings (ben@decadent.org.uk) wrote:
> These commits included in 2.6.32.12:
> 
> ea0a09acd81c6d52c77d80f0d4089795df7bcb58 "modules: fix incorrect percpu usage"
> d150a2b96558a7349cbf3a72a279c37bc67d50fb "module: fix __module_ref_addr()"

In addition to commit d150a2b96558a7349cbf3a72a279c37bc67d50fb, both commits:

ea0a09acd81c6d52c77d80f0d4089795df7bcb58 "modules: fix incorrect percpu usage"
b6b3dcd55e2327a968833ff3f22eda3b8dd7ef9e "lockdep: fix incorrect percpu usage"

Should be reverted from the 2.6.32.x -stable series. Quoting the explanation
from Tejun:

"I wrote on the bugzilla but this is not a compiler bug but the -stable
patch [shouldn't; edit: should] have been applied only to 2.6.33.  Not 2.6.32.
This is because till 2.6.32, ia64 hadn't been converted to dynamic percpu
allocator, so its static and dynamic percpu areas were separate and the
per_cpu_ptr() wouldn't do the offsetting the module code expects there.  So,
please revert the patch from 2.6.32."

Greg, it looks like we've not been clear enough about the fact that all three
commits needed to be reverted from the 2.6.32.x stable branch. Sorry about that.

Thanks,

Mathieu

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



-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

Attachment: signature.asc
Description: Digital signature


Reply to: