You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For this livepatch specifically it should be good to import the code as it was written, instead of copying the preprocessed one. When a livepatch is generated for multiple architectures, resolving cpu_to_le32 is problematic, since it changes according the machine architecture it's being generated on.
The text was updated successfully, but these errors were encountered:
It is not safe to extract code from x86_64 architecture to run on PPC, as the define paths would differ. The correct way of doing this would be to extract from both arch and compare the differences. If there are none, then it is safe to use on both, else you may need to merge the things together.
I agree. As we are using clang-extract as an experiment for kernel livepatches, maybe it would be nice to add some info about possible differences on the clang-extract README.md. Would it be safe to target PPC for example when generating code using clang-extract using cross compilation on a x86_64 machine? This would nice to have in the README as well.
When trying to create a livepatch for function ext4_reconfigure, file fs/ext4/super.c, on upstream, it generates the following code:
The original code, a macro in this case, has the following code on file fs/ext4/ext4.h:
For this livepatch specifically it should be good to import the code as it was written, instead of copying the preprocessed one. When a livepatch is generated for multiple architectures, resolving cpu_to_le32 is problematic, since it changes according the machine architecture it's being generated on.
The text was updated successfully, but these errors were encountered: