Liu Tao <ltao@xxxxxxxxxx> writes: > Hello Eric, > > Please correct me if I'm wrong. After my research, I found that the > KERNEL_VERSION > check cannot be removed. > > In x86_64 case, function get_kernel_page_offset set different hard coded > values into > elf_info->page_offset according to KERNEL_VERSION, then in function > get_kernel_vaddr_and_size, > elf_info->page_offset gets refreshed by reading program segments of > /proc/kcore. > The refresh can fail when KASLR is off, thus the hard coded values are > still needed as pre-set > default values. I see that the code is conditional upon KASLR, but I don't see any particular reason why the code in get_kernel_vaddr_and_size is conditional upon KASLR. Skimming through arch/x86/kernel/vmlinux.lds.S and fs/proc/kcore.c I don't see anything that is ASLR specific. So everything should work simply by removing the unnecessary gate on the presence of the page_address_base symbol. I suspect the code will even correctly compute PAGE_OFFSET on all architectures, but we don't need to go that far to remove our use of the kernel version. > In addition, If I set a wrong value in elf_info->page_offset, readelf -l > vmcore will give the value I set, > reading symbols in crash-utility is not affected. Especially if the reading the symbols is not affected by a wrong value just auto-detecting the value really seems to make the most sense. > From my point of view, extending the patch number from 8bit to 16bit is the > solution. Any thoughts? My thought is that in general the kernel version can not be depended upon for anything as there exist enterprise kernels that get feature backports. So there very easily could be a kernel where the kernel version does not accurately reflect what is going on. So unless we can say with certainty that there is no other way to detect the base address of the kernel we really don't want to use the kernel version. Right now it just looks like one all that is necessary is the removal of an unnecessary if check. Eric _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
