[PATCH] percpu: fix chunk range calculation

Tejun Heo tj at kernel.org
Mon Nov 21 16:10:50 EST 2011

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.



More information about the kexec mailing list