8000 kpatch:use vmlinux from first build by robinYin996 · Pull Request #1313 · dynup/kpatch · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

kpatch:use vmlinux from first build #1313

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

robinYin996
Copy link

We can use the first compiled vmlinux file from origin source code, and get the gcc version from the config file ,so we don't have to download kernel debuginfo(it's too big),and use kpatch-build command without '-v'

Signed-off-by: yinbinbin yinbinbin001@linux.alibaba.com

We can use the first compiled vmlinux file from origin source code,
and  get the gcc version from the config file ,so we don't have to
download kernel debuginfo(it's too big),and use kpatch-build command
without '-v'

Signed-off-by: yinbinbin <yinbinbin001@linux.alibaba.com>
Copy link
Member
@jpoimboe jpoimboe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting approach. If the original vmlinux isn't needed for the --sourcedir option, then it shouldn't be needed for any of the distro-specific options, and maybe we can just get rid of the --vmlinux option altogether, as well as the need for the debuginfo RPM.

Also, I think this highlights an existing bug in kpatch-build for the --sourcedir case where the vmlinux is in $USERSRCDIR. It reads the symbol table from the patched version of vmlinux, which could be dangerous if the patch altered the symbol table.

kernel_version < 4.18 get version from vmlinux(debuginfo)
kernel_version >= 4.18 get version from config file

Signed-off-by: yinbinbin <yinbinbin001@linux.alibaba.com>
@robinYin996
Copy link
Author

This is an interesting approach. If the original vmlinux isn't needed for the --sourcedir option, then it shouldn't be needed for any of the distro-specific options, and maybe we can just get rid of the --vmlinux option altogether, as well as the need for the debuginfo RPM.

Also, I think this highlights an existing bug in kpatch-build for the --sourcedir case where the vmlinux is in $USERSRCDIR. It reads the symbol table from the patched version of vmlinux, which could be dangerous if the patch altered the symbol table.

if "$VMLINUX" equal "$KERNEL_SRCDIR"/vmlinux file , kpatch-build will save original vmlinux before it gets overwritten

@robinYin996 robinYin996 requested a review from jpoimboe November 24, 2022 07:00
@jpoimboe
Copy link
Member
jpoimboe commented Dec 5, 2022

if "$VMLINUX" equal "$KERNEL_SRCDIR"/vmlinux file , kpatch-build will save original vmlinux before it gets overwritten

But it's not restored before readelf -s is run on it.

@jpoimboe
Copy link
Member
jpoimboe commented Dec 5, 2022

if "$VMLINUX" equal "$KERNEL_SRCDIR"/vmlinux file , kpatch-build will save original vmlinux before it gets overwritten

But it's not restored before readelf -s is run on it.

Never mind, I now see that VMLINUX gets changed to the original vmlinux in "$TEMPDIR/vmlinux" in that case.

@jpoimboe
Copy link
Member
jpoimboe commented Dec 6, 2022

I'm actually thinking we should try a slightly different approach.

There have been occasional bugs that caused the original vmlinux and the first compiled vmlinux to differ. See for example the commit log for commit 2e99d6b. Or, they could differ because the user made a mistake by using the wrong version of code or toolchain. Not having the old vmlinux would remove our ability to detect such cases.

In fact, I'd like to improve that detection by doing an explicit comparison of their symbol tables.

Though, in addition we could add a --skip-vmlinux-check option which would make $VMLINUX (and debuginfo) optional on newer kernels, which should solve your issue.

I'll open another PR with the proposed approach.

@jpoimboe
Copy link
Member
jpoimboe commented Dec 8, 2022

In fact, I'd like to improve that detection by doing an explicit comparison of their symbol tables.

So it turns out that on powerpc and s390 the symbol tables can get shuffled around when you add -ffunction-sections -fdata-sections. And sometimes symbols can even be removed. So it doesn't seem to be safe to use the first built vmlinux for symbol sympos lookups. And we don't want to have x86-specific functionality here, so as far as I can tell, debuginfo will be required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0