percpu: explain why per_cpu_ptr_to_phys() is more complicated than necessary
authorDave Young <dyoung@redhat.com>
Wed, 23 Nov 2011 16:20:53 +0000 (08:20 -0800)
committerTejun Heo <tj@kernel.org>
Wed, 23 Nov 2011 16:20:53 +0000 (08:20 -0800)
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 <dyoung@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
mm/percpu.c

index 2473ff06dc762e74f48a60a07e24fced18a0da47..3bb810a72006cd65e345e16fd124b61e029964db 100644 (file)
@@ -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.
  *
  * 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.
  */
  * RETURNS:
  * The physical address for @addr.
  */