From: Dave Young Date: Wed, 23 Nov 2011 16:20:53 +0000 (-0800) Subject: percpu: explain why per_cpu_ptr_to_phys() is more complicated than necessary X-Git-Url: https://openfabrics.org/gitweb/?a=commitdiff_plain;h=67589c71456b0346500629967292dea3802230b6;p=~shefty%2Frdma-dev.git percpu: explain why per_cpu_ptr_to_phys() is more complicated than necessary Add comments about current per_cpu_ptr_to_phys implementation to explain why the logic is more complicated than necessary. -tj: relocated comment into kerneldoc comment Signed-off-by: Dave Young Signed-off-by: Tejun Heo --- diff --git a/mm/percpu.c b/mm/percpu.c index 2473ff06dc7..3bb810a7200 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -978,6 +978,17 @@ bool is_kernel_percpu_address(unsigned long addr) * address. The caller is responsible for ensuring @addr stays valid * until this function finishes. * + * percpu allocator has special setup for the first chunk, which currently + * supports either embedding in linear address space or vmalloc mapping, + * and, from the second one, the backing allocator (currently either vm or + * km) provides translation. + * + * The addr can be tranlated simply without checking if it falls into the + * first chunk. But the current code reflects better how percpu allocator + * actually works, and the verification can discover both bugs in percpu + * allocator itself and per_cpu_ptr_to_phys() callers. So we keep current + * code. + * * RETURNS: * The physical address for @addr. */