Kdump issue with percpu_alloc=lpage

[John Blackwood]

 > Vivek Goyal wrote:
 > > > In kdump, we allocate per cpu area using alloc_percpu() and later
 > > > export the physical address of the area allocated to user space 
through
 > > > sysfs. (/sys/devices/system/cpu/cpuN/crash_notes). kexec-tools 
user space
 > > > utility makes use of this physical address to store in some ELF 
headers
 > > > which in turn are used by the second kernel booted after crash.
 > > >
 > > > We assume that address returned by per_cpu_ptr() is unity mapped and
 > > > use __pa() to convert that address to physical address.
 > > >
 > > > addr = __pa(per_cpu_ptr(crash_notes, cpunum));
 > > >
 > > > Is that not a valid assumption with percpu_alloc=lpage or 
percpu_alloc=4k
 > > > options? If not, what's the right way to get the physical address in
 > > > such situations?
 >
 > The lpage allocator is gone in the latest tree and only "embed" and
 > "page" allocators are there.  The only difference between the two is
 > that the embed one will put the first chunk inside the linearly mapped
 > area which in turn means that __pa() would work on static percpu
 > variables and some of dynamic ones but from the second chunk on and
 > for the page allocator, the percpu addresses will be remapped into
 > vmalloc area and behaves just like any other vmalloc address meaning
 > that the physical page can be determined using vmalloc_to_page().  So,
 > something like the following should work,
 >
 >         v = per_cpu_ptr(crash_notes, cpunum);
 >         if (v < VMALLOC_START || v >= VMALLOC_END)
 >                 p = __pa(v);
 >         else
 >                 p = page_to_phys(vmalloc_to_page(v));
 >
 > For the now removed lpage, it would be a bit difficult and we'll
 > probably need to add a dedicated function to percpu to determine the
 > physical address.  Hmmm... probably the right thing to do is to add
 > such function so that the user can simply call percpu_to_phys()
 > regardless of address?

Hi Tejun,

Just my 2 cent's worth...

I like the idea of having a percpu_to_phys() function that others can
call so that such detail are localized... and this also would tend to
be maintained better over time, since it would be more visible being
located near where the percpu support is implmented.

Thank you for the information.