Skip to content

create-diff-object: allow ignore not exist section#1465

Closed
wardenjohn wants to merge 1 commit intodynup:masterfrom
wardenjohn:allow_ignore_not_exist
Closed

create-diff-object: allow ignore not exist section#1465
wardenjohn wants to merge 1 commit intodynup:masterfrom
wardenjohn:allow_ignore_not_exist

Conversation

@wardenjohn
Copy link
Copy Markdown
Contributor

@wardenjohn wardenjohn commented Jun 19, 2025

When we adjust one patch with KPATCH_IGNORE_SECTION, different arch may different building action which may lead to this section not created under some arch.

For example:

create-diff-object: ERROR: inode.o: kpatch_mark_ignored_sections: 2993: KPATCH_IGNORE_SECTION: can't find .rela.return_sites

The ignored section is what we dont need, so, if this section is not exist, it should not do much effect to us since we try to throw it away. We should allow it continue to build.

@wardenjohn wardenjohn force-pushed the allow_ignore_not_exist branch from 98704a4 to 0eaa44b Compare June 19, 2025 02:53
When we adjust one patch with KPATCH_IGNORE_SECTION,
different arch may different building action which
may lead to this section not created under some arch.

For example:
```
create-diff-object: ERROR: inode.o: kpatch_mark_ignored_sections: 2993: KPATCH_IGNORE_SECTION: can't find .rela.return_sites
```

The ignored section is what we dont need, so, if this
section is not exist, it should not do much effect
to us since we try to throw it away. We should allow
it continue to build.

Signed-off-by: Wardenjohn <zhangwarden@gmail.com>
@wardenjohn wardenjohn force-pushed the allow_ignore_not_exist branch from 0eaa44b to 4d15b29 Compare June 19, 2025 09:39
@joe-lawrence
Copy link
Copy Markdown
Contributor

Hmm, I can see accepting or rejecting these missing ignored sections: On the one hand, the kpatch author may have crafted the patch specifically around that section and understands the implications of doing so -- in that case, if the build doesn't render the section, the author's assumptions have been violated. But, in cases like multi-architecture builds, I can see that the author may understand this and prefers the convenience.

Would a viable workaround just be to wrap the KPATCH_IGNORE_SECTION macro call in an #ifdef:

#ifdef CONFIG_X86_64
KPATCH_IGNORE_SECTION(foo);
#endif

or similar LINUX_VERSION_CODE type kernel version check? That way the kpatch is most expressive about why and when it's overriding the build tool behavior?

@wardenjohn
Copy link
Copy Markdown
Contributor Author

@joe-lawrence
Hi, Joe. In fact, when facing multi-arch builds, it is very easy to raise such situation.
Most of time, the code is written in a kernel function, like

int function_a(*) {
  int a;
  int b;
 a = a + b;
 // patch code, or something like this
 b = 2 * a;
}

And sometime some section like '.rela.return_site' will exist in some arch while other not. However, one patch used to build a livepatch.ko should be review by many experts. For example, we build it under x86, can find the '.rela.return_site' should be ignore. And it is urgent to fix it. After we build such livepatch.ko and apply to product environment, we all should be happy.

Unfortunately, a few weeks later, some kernel version with other arch also report this bug. We can try to fix it to build a new livepatch.ko under this arch. But this time, KPATCH_IGNORE_SECTION raise an error. The source code is the same, but we need to revert it becase we use git to manage our source code. It will be a nightmare becase the code state will be conflicted.

I am not sure if red hat would face this problem, but with the source code managed by git repo, I am afraid this will be a bad point...

@jpoimboe
Copy link
Copy Markdown
Member

jpoimboe commented Jul 8, 2025

I like @joe-lawrence 's suggestion:

#ifdef CONFIG_X86_64
KPATCH_IGNORE_SECTION(foo);
#endif

But also, I don't think ignoring .return_sites is safe... that's a special section which is already handled appropriately by create-diff-object.

@wardenjohn
Copy link
Copy Markdown
Contributor Author

@joe-lawrence @jpoimboe
OK, I will consider it from my side. Thanks~
And you can close this PR without merge~

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.

3 participants