On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote: [..] > >>> START QUOTE > > [PATCH v3 1/3] kdump: Introduce ELF header in new memory feature > > Currently for s390 we create the ELF core header in the 2nd kernel with > a small trick. We relocate the addresses in the ELF header in a way > that for the /proc/vmcore code it seems to be in the 1st kernel (old) > memory and the read_from_oldmem() returns the correct data. This allows > the /proc/vmcore code to use the ELF header in the 2nd kernel. > > >>> END QUOTE > > For our current zfcpdump project (see "[PATCH 3/3]s390/kdump: Use > vmcore for zfcpdump") we could no longer use this trick. Therefore we > sent you the patches to get a clean interface for ELF header creation > in the 2nd kernel. Hi Michael, Few more questions. - What's the difference between zfcpdump and kdump. I thought zfcpdump just boots specific kernel from fixed drive? If yes, why can't that kernel prepare headers in similar way as regular kdump kernel does and gain from kdump kernel swap trick? Also, we are accessing the contents of elf headers using physical address. If that's the case, does it make a difference if data is in old kernel's memory or new kernel's memory. We will use the physical address and create a temporary mapping and it should not make a difference whether same physical page is already mapped in current kernel or not. Only restriction this places is that all ELF header needs to be contiguous. I see that s390 code already creates elf headers using kzalloc_panic(). So memory allocated should by physically contiguous. So can't we just put __pa(elfcorebuf) in elfcorehdr_addr. And same is true for p_offset fields in PT_NOTE headers and everything should work fine? Only problem we can face is that at some point of time kzalloc() might not be able to contiguous memory request. We can handle that once s390 runs into those issues. You are anyway allocating memory using kzalloc(). And if this works for s390 kdump, it should work for zfcpdump too? Thanks Vivek
