Re: [PATCH 2/2 2.6.31-rc5 REPOST] percpu, sparc64: fix sparsepossible cpu map handling

[Ingo Molnar]

* Tejun Heo <tj@xxxxxxxxxx> wrote:

> percpu code has been assuming num_possible_cpus() == nr_cpu_ids which
> is incorrect if cpu_possible_map contains holes.  This causes percpu
> code to access beyond allocated memories and vmalloc areas.  On a
> sparc64 machine with cpus 0 and 2 (u60), this triggers the following
> warning or fails boot.
> 
>  WARNING: at /devel/tj/os/work/mm/vmalloc.c:106 vmap_page_range_noflush+0x1f0/0x240()
>  Modules linked in:
>  Call Trace:
>   [00000000004b17d0] vmap_page_range_noflush+0x1f0/0x240
>   [00000000004b1840] map_vm_area+0x20/0x60
>   [00000000004b1950] __vmalloc_area_node+0xd0/0x160
>   [0000000000593434] deflate_init+0x14/0xe0
>   [0000000000583b94] __crypto_alloc_tfm+0xd4/0x1e0
>   [00000000005844f0] crypto_alloc_base+0x50/0xa0
>   [000000000058b898] alg_test_comp+0x18/0x80
>   [000000000058dad4] alg_test+0x54/0x180
>   [000000000058af00] cryptomgr_test+0x40/0x60
>   [0000000000473098] kthread+0x58/0x80
>   [000000000042b590] kernel_thread+0x30/0x60
>   [0000000000472fd0] kthreadd+0xf0/0x160
>  ---[ end trace 429b268a213317ba ]---
> 
> This patch fixes generic percpu functions and sparc64
> setup_per_cpu_areas() so that they handle sparse cpu_possible_map
> properly.
> 
> Please note that on x86, cpu_possible_map() doesn't contain holes and
> thus num_possible_cpus() == nr_cpu_ids and this patch doesn't cause
> any behavior difference.
> 
> Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
> Cc: David S. Miller <davem@xxxxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxx>
> ---
> As written in the previous mail, this fixes rather critical boot
> problem on sparc64.  Upon ack, I can get it through the percpu tree.
> Not really sure who could ack this one other than David tho.  Anyone?
> 
> Thanks.
> 
>  arch/sparc/kernel/smp_64.c     |    4 ++--
>  arch/x86/kernel/setup_percpu.c |   14 +++++++-------
>  mm/percpu.c                    |   31 +++++++++++++++++++------------
>  3 files changed, 28 insertions(+), 21 deletions(-)

for the x86 bits:

 Acked-by: Ingo Molnar <mingo@xxxxxxx>

Once Dave acks it i suspect you can send it to Linus directly?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/