percpu: fix chunk range calculation
authorTejun Heo <tj@kernel.org>
Fri, 18 Nov 2011 18:55:35 +0000 (10:55 -0800)
committerGreg Kroah-Hartman <gregkh@suse.de>
Wed, 21 Dec 2011 20:57:37 +0000 (12:57 -0800)
commit6400c8a382ded237df5dc1605f0d06e7939ff4da
treeb1c13ae760a87d9d758e0741ab0e418d8a870915
parent5341e68f9b6c25c0a062de6d730034640988a605
percpu: fix chunk range calculation

commit a855b84c3d8c73220d4d3cd392a7bee7c83de70e upstream.

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@kernel.org>
Reported-by: WANG Cong <xiyou.wangcong@gmail.com>
Reported-by: Dave Young <dyoung@redhat.com>
Tested-by: Dave Young <dyoung@redhat.com>
LKML-Reference: <4EC21F67.10905@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/percpu-vm.c
mm/percpu.c