Re: kexec does not work for kernel version with patch level >= 256
Liu Tao 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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
Liu Tao writes: > Hello Eric, > > I'd like to have a try on this issue. > Since I'm not very familiar with the related code, maybe I need to spend a > little more time on it. Please give it a shot. Getting rid of explicit kernel version checks would be wonderful and prevent future problems as well. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
Greg KH writes: > On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote: >> Add Sasha and Greg to the CC list. >> >> On 03/31/21 at 11:48am, Baoquan He wrote: >> > On 03/31/21 at 11:04am, Patrick Sung wrote: >> > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote: >> > > > >> > > > On 03/24/21 at 12:28pm, Patrick Sung wrote: >> > > > > Hello all, >> > > > > >> > > > > I am using the 4.9 long term kernel which is currently at 4.9.262. >> > > > > When using this kernel with kexec-tools it prints out this error >> > > > > >> > > > > Unsupported utsname.release: 4.9.262 >> > > > > Cannot load >> > > > > >> > > > > A quick search in the code shows that kexec/kernel_version.c doing >> > > > > this check: >> > > > > >> > > > > if (major >= 256 || minor >= 256 || patch >= 256) { >> > > > > >> > > > > and also in kexec/kexec.h >> > > > > #define KERNEL_VERSION(major, minor, patch) \ >> > > > > (((major) << 16) | ((minor) << 8) | patch) >> > > > >> > > > Yeah, this seems to be a good catch. The existing longterm kenrel >> > > > 4.9.262 >> > > > does cause the problem. I am not very sure about the longterm kernel >> > > > version numbering, maybe we can leave 16 bits for for patch number to >> > > > avoid the longterm kernel issue? >> > > > >> > > > Is there document telling the longterm kernel version numbering, or any >> > > > pointer? >> > > > >> > > Actually I found that the mainline kernel clamp the "patch" version to >> > > 255 >> > > >> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0 >> > >> > Yeah, mainline kernel use below formula to construct kernel version. >> > Seems longterm kernel takes a different way. While it's understandable >> > that Longterm kernel using a larger patch number since it will evolve >> > evolve for a longer time to get in bug fixes. Maybe we should enlarge >> > patch number to 16 bits? >> > >> > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \ >> > >> > ((c) > 255 ? 255 : (c)))'; >> >> Should we also need to do the the same thing in kexec-tools utility, to >> clamp the sub-level to 255? And the sub-level number is not so important >> that we can do the clamping and won't cause any issue? > > If you can enlarge your "c" number to be 16bits, please do so. We > couldn't do that in the kernel source as it would break an existing > user/kernel api :( The code in kexec certainly can. The function kernel_version() returns a long. However. I think the code in kexec can do better. There are only 4 uses of KERNEL_VERSION in the tree and only one of them is testing for a case that would apply to kernel versions that are being maintained. AKA I think checks for 3.15 and 2.6.27 we can just delete. The checks for 3.15 are about command line size and are actively wrong. As checking the running kernel to find the version of the kernel that is being loaded is not reliable. Which leaves only one check and I think the information needed is X86_64_PAGE_OFFSET. I think that can be obtained directly by reading /proc/kcore instead of guessing it from the kernel version. Does anyone want to try that? I admit it is a bit more work than changing the macro to just add more bits to the patch level but it is would be more robust long term. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote: > Add Sasha and Greg to the CC list. > > On 03/31/21 at 11:48am, Baoquan He wrote: > > On 03/31/21 at 11:04am, Patrick Sung wrote: > > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote: > > > > > > > > On 03/24/21 at 12:28pm, Patrick Sung wrote: > > > > > Hello all, > > > > > > > > > > I am using the 4.9 long term kernel which is currently at 4.9.262. > > > > > When using this kernel with kexec-tools it prints out this error > > > > > > > > > > Unsupported utsname.release: 4.9.262 > > > > > Cannot load > > > > > > > > > > A quick search in the code shows that kexec/kernel_version.c doing > > > > > this check: > > > > > > > > > > if (major >= 256 || minor >= 256 || patch >= 256) { > > > > > > > > > > and also in kexec/kexec.h > > > > > #define KERNEL_VERSION(major, minor, patch) \ > > > > > (((major) << 16) | ((minor) << 8) | patch) > > > > > > > > Yeah, this seems to be a good catch. The existing longterm kenrel > > > > 4.9.262 > > > > does cause the problem. I am not very sure about the longterm kernel > > > > version numbering, maybe we can leave 16 bits for for patch number to > > > > avoid the longterm kernel issue? > > > > > > > > Is there document telling the longterm kernel version numbering, or any > > > > pointer? > > > > > > > Actually I found that the mainline kernel clamp the "patch" version to 255 > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0 > > > > Yeah, mainline kernel use below formula to construct kernel version. > > Seems longterm kernel takes a different way. While it's understandable > > that Longterm kernel using a larger patch number since it will evolve > > evolve for a longer time to get in bug fixes. Maybe we should enlarge > > patch number to 16 bits? > > > > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \ > > > > ((c) > 255 ? 255 : (c)))'; > > Should we also need to do the the same thing in kexec-tools utility, to > clamp the sub-level to 255? And the sub-level number is not so important > that we can do the clamping and won't cause any issue? If you can enlarge your "c" number to be 16bits, please do so. We couldn't do that in the kernel source as it would break an existing user/kernel api :( thanks, greg k-h ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
Add Sasha and Greg to the CC list. On 03/31/21 at 11:48am, Baoquan He wrote: > On 03/31/21 at 11:04am, Patrick Sung wrote: > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote: > > > > > > On 03/24/21 at 12:28pm, Patrick Sung wrote: > > > > Hello all, > > > > > > > > I am using the 4.9 long term kernel which is currently at 4.9.262. > > > > When using this kernel with kexec-tools it prints out this error > > > > > > > > Unsupported utsname.release: 4.9.262 > > > > Cannot load > > > > > > > > A quick search in the code shows that kexec/kernel_version.c doing this > > > > check: > > > > > > > > if (major >= 256 || minor >= 256 || patch >= 256) { > > > > > > > > and also in kexec/kexec.h > > > > #define KERNEL_VERSION(major, minor, patch) \ > > > > (((major) << 16) | ((minor) << 8) | patch) > > > > > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262 > > > does cause the problem. I am not very sure about the longterm kernel > > > version numbering, maybe we can leave 16 bits for for patch number to > > > avoid the longterm kernel issue? > > > > > > Is there document telling the longterm kernel version numbering, or any > > > pointer? > > > > > Actually I found that the mainline kernel clamp the "patch" version to 255 > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0 > > Yeah, mainline kernel use below formula to construct kernel version. > Seems longterm kernel takes a different way. While it's understandable > that Longterm kernel using a larger patch number since it will evolve > evolve for a longer time to get in bug fixes. Maybe we should enlarge > patch number to 16 bits? > > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \ > > ((c) > 255 ? 255 : (c)))'; Should we also need to do the the same thing in kexec-tools utility, to clamp the sub-level to 255? And the sub-level number is not so important that we can do the clamping and won't cause any issue? Thanks Baoquan > > By the way, it calls 'a' version number, 'b' patch level, 'c' sub-level > in Makefile of kernel? > > > > > > Thanks > > > Baoquan > > > > > > > > > > > which explains the reason for the range check in kernel_version.c > > > > > > > > Increasing the number of bits allowed in "patch" seems to fix the issue. > > > > > > > > Thanks, > > > > Patrick > > > > > > > > ___ > > > > kexec mailing list > > > > kexec@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/kexec > > > > > > > > > > > > ___ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
On 03/31/21 at 11:04am, Patrick Sung wrote: > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote: > > > > On 03/24/21 at 12:28pm, Patrick Sung wrote: > > > Hello all, > > > > > > I am using the 4.9 long term kernel which is currently at 4.9.262. > > > When using this kernel with kexec-tools it prints out this error > > > > > > Unsupported utsname.release: 4.9.262 > > > Cannot load > > > > > > A quick search in the code shows that kexec/kernel_version.c doing this > > > check: > > > > > > if (major >= 256 || minor >= 256 || patch >= 256) { > > > > > > and also in kexec/kexec.h > > > #define KERNEL_VERSION(major, minor, patch) \ > > > (((major) << 16) | ((minor) << 8) | patch) > > > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262 > > does cause the problem. I am not very sure about the longterm kernel > > version numbering, maybe we can leave 16 bits for for patch number to > > avoid the longterm kernel issue? > > > > Is there document telling the longterm kernel version numbering, or any > > pointer? > > > Actually I found that the mainline kernel clamp the "patch" version to 255 > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0 Yeah, mainline kernel use below formula to construct kernel version. Seems longterm kernel takes a different way. While it's understandable that Longterm kernel using a larger patch number since it will evolve evolve for a longer time to get in bug fixes. Maybe we should enlarge patch number to 16 bits? echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \ ((c) > 255 ? 255 : (c)))'; By the way, it calls 'a' version number, 'b' patch level, 'c' sub-level in Makefile of kernel? > > > Thanks > > Baoquan > > > > > > > > which explains the reason for the range check in kernel_version.c > > > > > > Increasing the number of bits allowed in "patch" seems to fix the issue. > > > > > > Thanks, > > > Patrick > > > > > > ___ > > > kexec mailing list > > > kexec@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/kexec > > > > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote: > > On 03/24/21 at 12:28pm, Patrick Sung wrote: > > Hello all, > > > > I am using the 4.9 long term kernel which is currently at 4.9.262. > > When using this kernel with kexec-tools it prints out this error > > > > Unsupported utsname.release: 4.9.262 > > Cannot load > > > > A quick search in the code shows that kexec/kernel_version.c doing this > > check: > > > > if (major >= 256 || minor >= 256 || patch >= 256) { > > > > and also in kexec/kexec.h > > #define KERNEL_VERSION(major, minor, patch) \ > > (((major) << 16) | ((minor) << 8) | patch) > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262 > does cause the problem. I am not very sure about the longterm kernel > version numbering, maybe we can leave 16 bits for for patch number to > avoid the longterm kernel issue? > > Is there document telling the longterm kernel version numbering, or any > pointer? > Actually I found that the mainline kernel clamp the "patch" version to 255 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0 > Thanks > Baoquan > > > > > which explains the reason for the range check in kernel_version.c > > > > Increasing the number of bits allowed in "patch" seems to fix the issue. > > > > Thanks, > > Patrick > > > > ___ > > kexec mailing list > > kexec@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
On 03/24/21 at 12:28pm, Patrick Sung wrote: > Hello all, > > I am using the 4.9 long term kernel which is currently at 4.9.262. > When using this kernel with kexec-tools it prints out this error > > Unsupported utsname.release: 4.9.262 > Cannot load > > A quick search in the code shows that kexec/kernel_version.c doing this check: > > if (major >= 256 || minor >= 256 || patch >= 256) { > > and also in kexec/kexec.h > #define KERNEL_VERSION(major, minor, patch) \ > (((major) << 16) | ((minor) << 8) | patch) Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262 does cause the problem. I am not very sure about the longterm kernel version numbering, maybe we can leave 16 bits for for patch number to avoid the longterm kernel issue? Is there document telling the longterm kernel version numbering, or any pointer? Thanks Baoquan > > which explains the reason for the range check in kernel_version.c > > Increasing the number of bits allowed in "patch" seems to fix the issue. > > Thanks, > Patrick > > ___ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
kexec does not work for kernel version with patch level >= 256
Hello all, I am using the 4.9 long term kernel which is currently at 4.9.262. When using this kernel with kexec-tools it prints out this error Unsupported utsname.release: 4.9.262 Cannot load A quick search in the code shows that kexec/kernel_version.c doing this check: if (major >= 256 || minor >= 256 || patch >= 256) { and also in kexec/kexec.h #define KERNEL_VERSION(major, minor, patch) \ (((major) << 16) | ((minor) << 8) | patch) which explains the reason for the range check in kernel_version.c Increasing the number of bits allowed in "patch" seems to fix the issue. Thanks, Patrick ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec