[PATCH] percpu: fix chunk range calculation

Dave Young dyoung at redhat.com
Mon Nov 21 21:48:28 EST 2011

On 11/22/2011 05:10 AM, Tejun Heo wrote:

> On Fri, Nov 18, 2011 at 10:55:35AM -0800, Tejun Heo wrote:
>> Percpu allocator recorded the cpus which map to the first and last
>> units in pcpu_first/last_unit_cpu respectively and used them to
>> determine the address range of a chunk - e.g. it assumed that the
>> first unit has the lowest address in a chunk while the last unit has
>> the highest address.
>> This simply isn't true.  Groups in a chunk can have arbitrary positive
>> or negative offsets from the previous one and there is no guarantee
>> that the first unit occupies the lowest offset while the last one the
>> highest.
>> Fix it by actually comparing unit offsets to determine cpus occupying
>> the lowest and highest offsets.  Also, rename pcu_first/last_unit_cpu
>> to pcpu_low/high_unit_cpu to avoid confusion.
>> The chunk address range is used to flush cache on vmalloc area
>> map/unmap and decide whether a given address is in the first chunk by
>> per_cpu_ptr_to_phys() and the bug was discovered by invalid
>> per_cpu_ptr_to_phys() translation for crash_note.
>> Kudos to Dave Young for tracking down the problem.
>> Signed-off-by: Tejun Heo <tj at kernel.org>
>> Reported-by: WANG Cong <xiyou.wangcong at gmail.com>
>> Reported-by: Dave Young <dyoung at redhat.com>
>> LKML-Reference: <4EC21F67.10905 at redhat.com>
>> Cc: stable @kernel.org
> BTW, waiting for Tested-by.  If someone gives me that, I'll push it
> through percpu/for-fixes.

Tested-by: Dave Young <dyoung at redhat.com>

> Thanks.


More information about the kexec mailing list