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 <bhe@xxxxxxxxxx> 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 <kdump images path>
> > > >
> > > > 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@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.infradead.org/mailman/listinfo/kexec
> > > >
> > >
> >
>
>
> _______________________________________________
> kexec mailing list
> kexec@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
