Arm64 support, including @surajjs95 & @t-msn changes #1302

swine · 2022-09-15T21:49:59Z

a rebase of @t-msn's rebase of earlier arm64 support from @surajjs95, tested with proposed kernel changes from https://lore.kernel.org/linux-arm-kernel/[email protected]

I haven't tested this with gcc yet, or shown it doesn't break powerpc or s390 behavior, but it might be a good base to collaborate on as an arm64-specific branch

While surajjs95's original version worked well with 5.10 kernel codebase (with v13 of madvenka's klp/arm64 changes), and earlier versions of clang, updates to kernel and clang have required changes to elf section namespace & clang local symbol namespace.

The most interesting change since Suraj's version is support for the multiple __patchable_function_entries sections that modern clang emits for arm64 (and riscv too, I hear). This version corrects defects in my early WIP tree, where sh_link was left unset in the ELF output's __patchable_function_entries sections.

I've omitted the earlier "WIP: create-diff-object: keep ubsan section" commit, as I haven't tested it, and neither had @t-msn.
That's added in the WIP @swine/kpatch/test branch, along with the 5.19 .cmd parsing changes from @jpoimboe which seems to work nicely on linux-6.0 for both vmlinux & module changes

joe-lawrence · 2022-09-20T16:13:57Z

Thanks @swine!

BTW, I wonder if development of kpatch-build for arm64 would be easier if we were to merge work to a temporary development branch? That would facilitate contributions from multiple folks without having to carry the entire history over and over again... and then we just periodically rebase to keep up with master until the work is ready. Just a thought.

On the PR:

check out the build tests that are failing (looks pretty minor at first glance)
how many of the new clang issues would affect x86? could we spin those out to merge sooner than later?
do you happen to know what post v5.10 patches Madhavan's latest patchset now depends on?

swine · 2022-09-20T20:20:57Z

I have yet to try this against ubuntu/x86 to understand what broke in the build/unit-tests

Probably a better way of layering arm64 support, since @t-msn has published a similar gcc-focused arm64 rebase, is to layer these partially clang-related changes atop t-msn's, if they address similar issues in compatible ways.
I've not reviewed t-msn's changes deeply, while much of it looked familiar from Suraj's earlier work, there are some apparently gcc-namespace (or post-5.15 kernel namespace) related issues that should be merged earlier than my clang-namespace changes, as most of the community is still gcc-centric, and the unit tests are by default (or always?) using gcc

Next layer to merge would be clang/x86 issues, and finally the clang/arm64 issues, including the multiple-__patchable_function_entries ELF sections that arm64/riscv now generate

Re: "what post v5.10 patches Madhavan's latest kernel patchset now depends on" ...

This kpatch patchset has been developed against Madhavan's kernel work, as it evolved from v5.12 thru 5.19, and targeting our 5.10 & 5.15 clang-built frankenkernels.

With 5.15/clang, Madhavan's latest objtool-using 5.19-based kernel changes backported easily with 26 supporting objtool backports, and a few other kernel cherry-picks, bridging the 5.15..5.19 gap. This is working reliably on 5.15, passing all our kpatch/klp tests

We're currently backporting this to 5.10, where Madhavan's v13 kernel patches were working nicely (the pre-objtool version relying on SYM_CODE/SYM_FUNC markings), with a few supporting backports in ftrace/etc infrastructure.
But backporting Madhavan's latest objtool-based patchset to 5.10 is still a work in progress - it still needs the ftrace/etc support, but also needs about 70! backports of the objtool evolution between 5.10..5.15.
Most of these are clean cherry-picks into a pure 5.10 tree, but we're still debugging - builds for both x86/arm64, but patches fail to apply, so something is broken, probably the objtool merges.

I'm sure the arm64 objtool changes could be backported without most of the intervening 5.10...5.19 evolution of largely-x86-specific functionality, but since we aggressively backport objtool changes for retpoline & ebpf support anyway, it seems cleaner to bring the whole baseline up closer to upstream, than to diverge further, forking objtool for 3 distinct needs.

The objtool-using patchset is certainly the preferred kernel solution - verifying sane frame-pointer semantics rather than relying on developers to keep SYM_CODE/SYM_FUNC markings accurate.

t-msn · 2022-09-21T02:44:39Z

Hello, @joe-lawrence
To clarify, my rebase branch @swine mentioned is here, which I described in the original PR comment )
My rebase is another rebase to master branch based on your rebase and does not care clang build at this point.

swine's comment
I've not reviewed t-msn's changes deeply, while much of it looked familiar from Suraj's earlier work,

Basically I tried to keep the original patches' structure as possible.

I checked that the differences of rebase at the commit "kpatch-build: Enable ARM64 support" (i.e. mine and swine's).
I think one notable difference is that swine's version addresses .static_call_sites sections which didn't care in the original patch.
After that commit, my rebase branch contains joe-lawrence's unit tests commit for arm64 and some small fixes.

joe-lawrence's comment
BTW, I wonder if development of kpatch-build for arm64 would be easier if we were to merge work to a temporary development branch? That would facilitate contributions from multiple folks without having to carry the entire history over and over again... and then we just periodically rebase to keep up with master until the work is ready. Just a thought.

I agree this so that people can easily test and develop using the shared code (i.e. rebased original PR + unit tests). I'm not sure what is the best way but for me it is both ok to create another PR with my rebase code or to split this PR up to "Enable ARM64 support". Any thoughts?

joe-lawrence · 2022-09-22T14:08:09Z

I have yet to try this against ubuntu/x86 to understand what broke in the build/unit-tests

Probably a better way of layering arm64 support, since @t-msn has published a similar gcc-focused arm64 rebase, is to layer these partially clang-related changes atop t-msn's, if they address similar issues in compatible ways. I've not reviewed t-msn's changes deeply, while much of it looked familiar from Suraj's earlier work, there are some apparently gcc-namespace (or post-5.15 kernel namespace) related issues that should be merged earlier than my clang-namespace changes, as most of the community is still gcc-centric, and the unit tests are by default (or always?) using gcc

Yes, unit tests are cached gcc-generated original/patched object files. We can add clang generated object files if there are issues specific to its toolchain. Curation of the unit test object files is unfortunately a manual process, but at least that makes it easy to add "clang-test-foo.o" files to the suite.

Regarding the two MRs, rebases of rebases, etc. are starting to get hard to track... so what about this strategy largely based on your suggestion:

@swine / @joe-lawrence opens a new PR with clang/x86 related issues from this set. We can review and merge these independently and sooner than any of the arm64 related ones. BTW, we have hit some of these issues internally (like .llvm* sections, .shstrtab, etc.) but haven't had time to fix them, hence my interest.
@joe-lawrence creates a new aarch64-development branch based on @t-msn's rebase. As noted, this branch looks cleanest with respect to handling arch-specific C code from the onset.
2a. We can periodically rebase and force push to keep up with master
2b. Fixes to these commits can be squashed as part of periodic rebase (2a).
2c. New development can just add new commits as usual
@swine opens a new PR on top of (2) with toolchain-generic arm fixes like: ("harvest paravirt/alt_instr sizes for 5.15"), ("arm64 leaf-function fix"), ("kpatch-cc skip arch/arm64/kernel/vdso*/*") These would follow step (2c) above so that gcc based development can benefit, too.
@swine opens a new PR on top of (2) with clang/specific arm64 fixes.

Re: "what post v5.10 patches Madhavan's latest kernel patchset now depends on" ...

This kpatch patchset has been developed against Madhavan's kernel work, as it evolved from v5.12 thru 5.19, and targeting our 5.10 & 5.15 clang-built frankenkernels.

With 5.15/clang, Madhavan's latest objtool-using 5.19-based kernel changes backported easily with 26 supporting objtool backports, and a few other kernel cherry-picks, bridging the 5.15..5.19 gap. This is working reliably on 5.15, passing all our kpatch/klp tests

We're currently backporting this to 5.10, where Madhavan's v13 kernel patches were working nicely (the pre-objtool version relying on SYM_CODE/SYM_FUNC markings), with a few supporting backports in ftrace/etc infrastructure. But backporting Madhavan's latest objtool-based patchset to 5.10 is still a work in progress - it still needs the ftrace/etc support, but also needs about 70! backports of the objtool evolution between 5.10..5.15. Most of these are clean cherry-picks into a pure 5.10 tree, but we're still debugging - builds for both x86/arm64, but patches fail to apply, so something is broken, probably the objtool merges.

I'm sure the arm64 objtool changes could be backported without most of the intervening 5.10...5.19 evolution of largely-x86-specific functionality, but since we aggressively backport objtool changes for retpoline & ebpf support anyway, it seems cleaner to bring the whole baseline up closer to upstream, than to diverge further, forking objtool for 3 distinct needs.

The objtool-using patchset is certainly the preferred kernel solution - verifying sane frame-pointer semantics rather than relying on developers to keep SYM_CODE/SYM_FUNC markings accurate.

Thanks for the details! I haven't looked at Madhavan's latest few versions, so I am asking as rhel-9 franken-kernel backports are starting to get interesting, too.

joe-lawrence · 2022-09-22T21:08:11Z

I have yet to try this against ubuntu/x86 to understand what broke in the build/unit-tests

I think the problem is that kelf_orig has been freed before calling has_multi_pfe():

kpatch_elf_teardown(kelf_orig);
kpatch_elf_free(kelf_orig);
...
multi_pfe = has_multi_pfe(kelf_orig) || has_multi_pfe(kelf_patched);

t-msn · 2022-09-23T03:02:12Z

@joe-lawrence

Regarding the two MRs, rebases of rebases, etc. are starting to get hard to track... so what about this strategy largely based on your suggestion:

I have no objections for this approach. Thank you very much for you effort.

@joe-lawrence creates a new aarch64-development branch based on @t-msn's rebase. As noted, this branch looks cleanest with respect to handling arch-specific C code from the onset.

It might be easier for you to rebase by yourself than using my rebase and it is just fine.
If using my rebase branch, please ignore the last commit (i.e. ubsan fix) as I found that it is not the right fix nor the problem is only arm64 specific. Also squash my fix commits if it is suitable.

swine · 2022-10-13T02:59:45Z

See updated description - now based on @t-msn changes laid over master, may be candidate for a temporarily arm64-specific branch until it's shown harmless to other platforms

t-msn · 2022-10-14T11:34:53Z

kpatch-build/create-diff-object.c

+			if (multi_pfe)
+				sec->sh.sh_link = 0; /* set later */
+			else
+				sec->sh.sh_link = text_idx;


I saw the following error with gcc12 for integration test (data-new etc.):

ld: __patchable_function_entries has both ordered and unordered sections

Bisect points this commit. With additional log messages, I found text_idx is 0 and it causes the problem.
Should we set sh_link later like when multi_pfe is true or set 1 unconditionally just like before this commit?
(I'm looking this comment...: #1236 (comment))

I think the issue was that multi_pfe was getting set too late.
Next push should resolve that

Hi @swine, I'm still seeing

ld: __patchable_function_entries has both ordered and unordered sections

with gcc12 and your latest push (2023.1.16, d01cbc2), set sh_link to 1 unconditionally for non-multi_pfe case fixed the issue for me.

joe-lawrence

Thanks for updating, @swine. See a few inline comments on various bits of code.

Then to save dragging these through future rebases, can you spin out the following patches as their own PR? They don't appear to be arm64-arch dependencies:

("kpatch-build: determine ARCH from $VMLINUX ")
("allow env override of toolchain")
("Read backported klp capabilities from <linux/livepatch.h>")
("simplify CC/LD patterns")
("add --make-opt, --cdo-opt")

kpatch-build/kpatch-build

joe-lawrence · 2022-10-14T13:54:06Z

kpatch-build/kpatch-cc

@@ -23,7 +23,7 @@ if [[ "$TOOLCHAINCMD" =~ ^(.*-)?gcc$ || "$TOOLCHAINCMD" =~ ^(.*-)?clang$ ]] ; th
 			[[ "$obj" = */.tmp_mc_*.o ]] && break;

 			[[ "$obj" = */.tmp_*.o ]] && obj="${obj/.tmp_/}"
-			relobj=${obj##$KPATCH_GCC_SRCDIR/}


Like the other string substitution update, seems unrelated to overriding the toolchain... did shellcheck complain or did you hit other problems with quoting these strings?

These were for calming shellcheck, possibly a different version of shellcheck than github uses.
Having been nagged by github's shellcheck, I updated it locally and resolved all its quibbles

kpatch-build/create-diff-object.c

jpoimboe

In addition to the individual code comments:

Please no version changelog information in the commit logs
Commit 0b09a57 ("create-diff-object: Create __patchable_function_entries section for aarch64") updates test/unit/objs. I don't think that was intentional?

kpatch-build/create-diff-object.c

jpoimboe · 2022-10-26T00:44:34Z

kpatch-build/create-diff-object.c

+		if (sec) {
+			flags = (sec->sh.sh_flags & (SHF_LINK_ORDER|SHF_WRITE));
+			if (sec->rela)
+				rflags = (sec->rela->sh.sh_flags & (SHF_LINK_ORDER|SHF_WRITE));


If the use of the SHF_LINK_ORDER flag is compiler-specific, maybe the "does pfe have the order flag" check can be done earlier, and stored as a pfe_link_order global variable. Then you don't need the whole alloc/populate split? Or does the flag actually change per section??

jpoimboe · 2022-10-26T01:11:04Z

kpatch-build/create-diff-object.c

@@ -788,6 +838,84 @@ static bool kpatch_line_macro_change_only(struct kpatch_elf *kelf,
 	return true;
 }

+static bool _kpatch_line_macro_change_only_aarch64(struct kpatch_elf *kelf,


Do we really need an arm64-specific version? At least from a quick glance I don't see why the generic version wouldn't work.

kpatch-build/create-diff-object.c

kpatch-build/kpatch-elf.c

kpatch-build/create-diff-object.c

swine · 2022-11-03T23:37:01Z

in the final kernel-or-object link all the surviving __pfe sections are collapsed into one. I'll explore further with maskray on which versions this lands in, and whether I've got the whole issue wrong

…

-pete

On Wed, Nov 2, 2022 at 8:50 AM Josh Poimboeuf ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In kpatch-build/create-diff-object.c <#1302 (comment)>: > continue; switch(kelf->arch) { + case AARCH64: { + struct section *sec; + + list_for_each_entry(sec, &kelf->sections, list) { + if (strcmp(sec->name, "__patchable_function_entries")) + continue; From a kernel standpoint this seems more like an anti-feature, since IIUC it adds hundreds of thousands of extra sections and bloats the object file size, with no benefit for the kernel. It would be nice if there were a flag to toggle this behavior. Also I'm still not able to recreate it with upstream Clang, maybe I'm doing something wrong? — Reply to this email directly, view it on GitHub <#1302 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH4XE6ISZR6YF3VQEPRR4TWGKEUPANCNFSM6AAAAAAQNZK4AY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

OpenCloudOS is a centos-like Linux distribution. I test kpatch in OpenCloudOS V8 and V9. It works well in V9. But v8 itself has two problems: 1. no available epol repo, so kpatch can't install ccache. 2. executing 'uname -r' can't get an accurate kernel version. Both problems have been notified to the OpenCloudOS community. After they fix these problems, kpatch will work well in all versions. Signed-off-by: Longjun Luo <[email protected]>

Signed-off-by: Ryan Sullivan <[email protected]>

If the kernel log is empty prior to running the integration tests, the following confusing status may be reported: ... ERROR: dmesg overflow, try increasing kernel log buffer size SUCCESS This occurs because the script can't find an empty dmesg entry when the tests are complete. Copy the upstream kernel livepatching kselftests to fix this by logging a canary message at the beginning of the integration tests. This will ensure a "real" message than can be found at the end. Fixes: de1d0c6 ("kpatch-test: don't clear dmesg during test") Signed-off-by: Joe Lawrence <[email protected]>

Upstream kernel commit f7af6977621a ("x86/paravirt: Remove no longer needed paravirt patching code") v6.8+ removed the .parainstructions section and its paravirt_patch_site struct. Therefore this checks the kernel version and does not export the struct size if the kernel version is >= v6.8.0, avoiding the code path for it in create-diff-object.c entirely. Fixes: dynup#1380 Signed-off-by: Ryan Sullivan <[email protected]>

Upstream kernel v6.1+ commit linux@e1789d7c752e ("kbuild: upgrade the orphan section warning to an error if CONFIG_WERROR is set") and CONFIG_WERROR will result in failed kernel builds due to the linker reporting tons of "unplaced orphan section `.text.<function>` <object-file.o>" errors. Workaround this by temporarily demoting such errors in the top-level kernel Makefile. Reported-and-tested-by: Zhijun Wang <[email protected]> Closes: dynup#1391 ("CONFIG_WERROR=y and CONFIG_LD_ORPHAN_WARN_LEVEL="error" break kpatch-build") Signed-off-by: Joe Lawrence <[email protected]>

Temporarily editing kernel tree sources has become a recurring requirement in kpatch-build. Pull the saving/restoring of these files into a common function helpers to standardize the pattern. Reported-and-tested-by: Zhijun Wang <[email protected]> Signed-off-by: Joe Lawrence <[email protected]>

Fix formatting issue and date error

The "has_function_profiling" support field in the symbol struct is used to show that a function symbol is able to be patched. This is necessary to check that functions which need to be patched are able to be. On arm64 this means the presence of 2 NOP instructions at function entry which are patched by ftrace to call the ftrace handling code. These 2 NOPs are inserted by the compiler and the location of them is recorded in a section called "__patchable_function_entries". Check whether a symbol has a corresponding entry in the "__patchable_function_entries" section and if so mark it as "has_func_profiling". Signed-off-by: Suraj Jitindar Singh <[email protected]> --- V1->V2: - Make error message standard across architectures when no patchable entry - Don't store __patchable_function_entries section in kpatch_find_func_profiling_calls(), instead find it each time

…d populate The function kpatch_create_mcount_sections() allocates the __mcount_loc section and then populates it with functions which have a patchable entry. The following patch will add aarch64 support to this function where the allocation will have to be done before the kelf_patched is torn down. Thus split this function so that the allocation can be performed earlier and the populating as before. No intended functional change. Signed-off-by: Suraj Jitindar Singh <[email protected]> --- V1->V2: - Add patch to series

…arch64 The __mcount_loc section contains the addresses of patchable ftrace sites which is used by the ftrace infrastructure in the kernel to create a list of tracable functions and to know where to patch to enable tracing of them. On aarch64 this section is called __patchable_function_entries and is generated by the compiler. Either of __mcount_loc or __patchable_function_entries is recognised by the kernel but for aarch64 use __patchable_function_entries as it is what is expected. Add aarch64 support to kpatch_alloc_mcount_sections(). The SHF_LINK_ORDER section flag must be copied to ensure that it matches to avoid the following: ld: __patchable_function_entries has both ordered [...] and unordered [...] sections Add aarch64 support to kpatch_populate_mcount_sections(). Check for the 2 required NOP instructions on function entry, which may be preceded by a BTI C instruction depending on whether the function is a leaf function. This determines the offset of the patch site. Signed-off-by: Suraj Jitindar Singh <[email protected]> --- V1->V2: - Don't preserve the __patchable_function_entries section from the patched elf as this is already verified by kpatch_check_func_profiling_calls() - Instead get the patch entry offset by checking for a preceding BTI C instr - Copy the section flags for __patchable_function_entries --- rebased, added sh_link fix from Suraj's later commit "kpatch-build: Enable ARM64 support" Signed-off-by: Pete Swain <[email protected]>

Add the final support required for aarch64 and enable building on that arch. Signed-off-by: Suraj Jitindar Singh <[email protected]> --- V1->V2: - Add # shellcheck disable=SC2086 - Add comment to kpatch_is_mapping_symbol()

On aarch64, only the ASSERT_RTNL macro is affected by source line number changes (WARN, BUG, etc. no longer embed line numbers in the instruction stream.) A small test function that invokes the macro for a line change from 42 to 43: 0000000000000000 <test_assert_rtnl>: 0: d503245f bti c 4: d503201f nop 8: d503201f nop c: d503233f paciasp 10: a9bf7bfd stp x29, x30, [sp, #-16]! 14: 910003fd mov x29, sp 18: 94000000 bl 0 <rtnl_is_locked> 18: R_AARCH64_CALL26 rtnl_is_locked 1c: 34000080 cbz w0, 2c <test_assert_rtnl+0x2c> 20: a8c17bfd ldp x29, x30, [sp], dynup#16 24: d50323bf autiasp 28: d65f03c0 ret 2c: 90000000 adrp x0, 0 <test_assert_rtnl> 2c: R_AARCH64_ADR_PREL_PG_HI21 .data.once 30: 39400001 ldrb w1, [x0] 30: R_AARCH64_LDST8_ABS_LO12_NC .data.once 34: 35ffff61 cbnz w1, 20 <test_assert_rtnl+0x20> 38: 52800022 mov w2, #0x1 // #1 3c: 90000001 adrp x1, 0 <test_assert_rtnl> 3c: R_AARCH64_ADR_PREL_PG_HI21 .rodata.str1.8+0x8 40: 39000002 strb w2, [x0] 40: R_AARCH64_LDST8_ABS_LO12_NC .data.once 44: 91000021 add x1, x1, #0x0 44: R_AARCH64_ADD_ABS_LO12_NC .rodata.str1.8+0x8 - 48: 52800542 mov w2, #0x2a // dynup#42 + 48: 52800562 mov w2, #0x2b // dynup#43 4c: 90000000 adrp x0, 0 <test_assert_rtnl> 4c: R_AARCH64_ADR_PREL_PG_HI21 .rodata.str1.8+0x20 50: 91000000 add x0, x0, #0x0 50: R_AARCH64_ADD_ABS_LO12_NC .rodata.str1.8+0x20 54: 94000000 bl 0 <__warn_printk> 54: R_AARCH64_CALL26 __warn_printk 58: d4210000 brk #0x800 5c: 17fffff1 b 20 <test_assert_rtnl+0x20> Create an implementation of kpatch_line_macro_change_only() for aarch64 modeled after the other architectures. Only look for relocations to __warn_printk that ASSERT_RTNL invokes. Based-on-s390x-code-by: C. Erastus Toe <[email protected]> Signed-off-by: Joe Lawrence <[email protected]>

Update the kpatch-unit-test-objs submodule reference to add aarch64 unit tests. Signed-off-by: Joe Lawrence <[email protected]>

It seems mapping symbols in aarch64 elf has section size of 0. So, exclude it in section symbol replacing code just like kpatch_correlate_symbols(). This fixes the data-read-mostly unit test on aarch64. Signed-off-by: Misono Tomohiro <[email protected]>

Copy from kernel source tree. Signed-off-by: Misono Tomohiro <[email protected]>

new clang toolchain on arm64 produces individual __patchable_function_entries sections for each patchable func, in -ffunction-sections mode, rather than traditional single __mcount_loc section. Bend the existing logic to detect this multiplicity in the incoming kelf objects, and allocate N identical one-entry sections. These are retrieved as needed by a new function: find_nth_section_by_name() and attached to the .text sections they describe. These __pfe section are not actually arm64-specific, but a generic enhancement across gcc & clang, to allow better garbage collection of unreferenced object sections, and mcount/pfe objects which refer to them. The __pfe sections are combined in kernel-or-module final link, from 5.19.9's 9440155ccb948f8e3ce5308907a2e7378799be60. From clang-11, __pfe is supported for x86, though not yet used by kernel The split between allocate/populate phases here is necessary to enumerate/populate the outgoing section-headers before beginning to produce output sections Also adds some missing \n to log_debug()s Signed-off-by: Pete Swain <[email protected]>

On arm64, kpatch_find_func_profiling_calls() was skipping leaf functions, with no relocations, so they weren't patchable. Here other archs need to walk a function's reloc entries to check for __fentry__ or __mcount, so it's valid to skip over functions without sym->sec->rela, because they cannot be patchable, else they would have at least an __fentry__ call relocation. But arm64 marks functions patchable in a different way, with per-func __patchable_function_entries sections referring _to_ the func, not relocations _within_ the func, so a function w/o relocations for text or data can still be patchable. Move the sym->sec->rela check to the per-arch paths. This allows gcc-static-local-var-5.patch to generate livepatch, on arm64 & x86 Suggested-By: Bill Wendling <[email protected]> Signed-off-by: Pete Swain <[email protected]>

Signed-off-by: Pete Swain <[email protected]>

New toolchain/arch, new conventions for section/label/etc names gcc's .LCx symbols point to string literals in '.rodata.<func>.str1.*' sections. Clang creates similar .Ltmp%d symbols in '.rodata.str' The function is_string_literal_section() generalized (too much?) to match either - clang's/arm64 /^\.rodata\.str$/ - gcc's /^\.rodata\./ && /\.str1\./ Various matchers for .data.unlikely .bss.unlikely replaced by is_data_unlikely_section() generalized to match - gcc's ".data.unlikely" - clang's ".(data|bss).module_name.unlikely" .data.once handled similarly Signed-off-by: Pete Swain <[email protected]>

merged in joe-lawrence/ppc64le-remove-eh_frame-take2 this should resolve github's test failures

Generalized kpatch_line_macro_change_only() & insn_is_load_immediate() to collapse the aarch64 support back into parent. I'm assuming the 3rd start1 of the original /* Verify mov w2 <line number> */ if (((start1[offset] & 0b11111) != 0x2) || (start1[offset+3] != 0x52) || ((start1[offset] & 0b11111) != 0x2) || (start2[offset+3] != 0x52)) was a typo for start2. That's now absorbed into insn_is_load_immediate() leaving just one aarch64-specific piece: thinning out the match-list for diagnosing a __LINE__ reference, to just "__warn_printf".

If CONFIG_UBSAN is enabled, ubsan section (.data..Lubsan_{data,type}) can be created. Keep them unconditionally. NOTE: This patch needs to be verified. Signed-off-by: Misono Tomohiro <[email protected]>

Initialize add_off earlier, so it's obviously never used uninitialized. Clang was warning on this, even if gcc was not. No functional change, the only path which left it undefined would call ERROR() anyway.

In ARM64, every function section should have its own pfe section. It is a bug in GCC 11/12 which will only generate a single pfe section for all functions. The bug has been fixed in GCC 13.1. As the create-diff-object is generating the pfe sections on its own, we should also fix this bug, instead of try to repeat the bug. -- Adjusted whitespace in Zimao's proposed code. Signed-off-by: Pete Swain <[email protected]>

Set pfe_per_function default to false.

This was referenced Sep 15, 2022

What do I need to do to support arm64? #1216

Closed

Add Arm64 Support #1236

Closed

swine force-pushed the arm64 branch from cbfc0b8 to 3e7a46e Compare September 17, 2022 03:30

swine force-pushed the arm64 branch from 3e7a46e to 6bd90c6 Compare September 20, 2022 22:11

joe-lawrence mentioned this pull request Sep 27, 2022

Collection of small llvm fixes #1305

Merged

swine force-pushed the arm64 branch 8 times, most recently from 7352145 to be7587c Compare October 11, 2022 09:18

swine force-pushed the arm64 branch from be7587c to f4b626b Compare October 12, 2022 17:05

swine marked this pull request as ready for review October 13, 2022 02:59

swine changed the title ~~Arm64 rebase (work in progress)~~ Arm64 support, including @surajjs95 & @t-msn changes Oct 13, 2022

t-msn reviewed Oct 14, 2022

View reviewed changes

joe-lawrence reviewed Oct 14, 2022

View reviewed changes

swine force-pushed the arm64 branch from f4b626b to be5da15 Compare October 20, 2022 09:04

jpoimboe reviewed Oct 26, 2022

View reviewed changes

swine force-pushed the arm64 branch 2 times, most recently from d5888f2 to d01cbc2 Compare January 9, 2023 11:09

anatasluo and others added 27 commits May 31, 2024 15:20

test/integration/rhel-8.10: add kernel-4.18.0-552.el8_10 tests

936afb9

Signed-off-by: Ryan Sullivan <[email protected]>

test/integration/rhel-9.4: add kernel-5.14.0-427.13.1.el9_4 tests

e86e0cf

Signed-off-by: Ryan Sullivan <[email protected]>

Update spec file

c8e6949

Fix formatting issue and date error

kpatch-build: Enable ARM64 support

3650f3a

Add the final support required for aarch64 and enable building on that arch. Signed-off-by: Suraj Jitindar Singh <[email protected]> --- V1->V2: - Add # shellcheck disable=SC2086 - Add comment to kpatch_is_mapping_symbol()

testing: add aarch unit tests

62e3ba3

Update the kpatch-unit-test-objs submodule reference to add aarch64 unit tests. Signed-off-by: Joe Lawrence <[email protected]>

kpatch-syscall.h: add aarch64 helper

9479442

Copy from kernel source tree. Signed-off-by: Misono Tomohiro <[email protected]>

doc/arm64-upstream-prerequisites.md

a475523

kpatch-cc skip arch/arm64/kernel/vdso*/*

9dd4923

Signed-off-by: Pete Swain <[email protected]>

testing: freshen unit tests to address ppc64le fails

5c31d6a

merged in joe-lawrence/ppc64le-remove-eh_frame-take2 this should resolve github's test failures

create-diff-object: keep ubsan section

3005626

If CONFIG_UBSAN is enabled, ubsan section (.data..Lubsan_{data,type}) can be created. Keep them unconditionally. NOTE: This patch needs to be verified. Signed-off-by: Misono Tomohiro <[email protected]>

uninit var in kpatch-elf.c

41375b5

Initialize add_off earlier, so it's obviously never used uninitialized. Clang was warning on this, even if gcc was not. No functional change, the only path which left it undefined would call ERROR() anyway.

create-diff-object: add init value for pfe flag

9b261ab

Set pfe_per_function default to false.

swine force-pushed the arm64 branch from 7b3ebf8 to 9b261ab Compare May 31, 2024 22:31

Merge branch 'master' into arm64

3fb4582

mihails-strasuns mentioned this pull request Sep 5, 2024

Rebase of aarch64 PR #1414

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Arm64 support, including @surajjs95 & @t-msn changes #1302

Arm64 support, including @surajjs95 & @t-msn changes #1302

swine commented Sep 15, 2022 •

edited

Loading

joe-lawrence commented Sep 20, 2022

swine commented Sep 20, 2022

t-msn commented Sep 21, 2022

joe-lawrence commented Sep 22, 2022

joe-lawrence commented Sep 22, 2022

t-msn commented Sep 23, 2022 •

edited

Loading

swine commented Oct 13, 2022

t-msn Oct 14, 2022

swine Oct 17, 2022

ryncsn Jan 16, 2023 •

edited

Loading

joe-lawrence left a comment

joe-lawrence Oct 14, 2022

swine Oct 14, 2022

jpoimboe left a comment

jpoimboe Oct 26, 2022

jpoimboe Oct 26, 2022

swine commented Nov 3, 2022 via email

Arm64 support, including @surajjs95 & @t-msn changes #1302

Are you sure you want to change the base?

Arm64 support, including @surajjs95 & @t-msn changes #1302

Conversation

swine commented Sep 15, 2022 • edited Loading

joe-lawrence commented Sep 20, 2022

swine commented Sep 20, 2022

t-msn commented Sep 21, 2022

joe-lawrence commented Sep 22, 2022

joe-lawrence commented Sep 22, 2022

t-msn commented Sep 23, 2022 • edited Loading

swine commented Oct 13, 2022

t-msn Oct 14, 2022

Choose a reason for hiding this comment

swine Oct 17, 2022

Choose a reason for hiding this comment

ryncsn Jan 16, 2023 • edited Loading

Choose a reason for hiding this comment

joe-lawrence left a comment

Choose a reason for hiding this comment

joe-lawrence Oct 14, 2022

Choose a reason for hiding this comment

swine Oct 14, 2022

Choose a reason for hiding this comment

jpoimboe left a comment

Choose a reason for hiding this comment

jpoimboe Oct 26, 2022

Choose a reason for hiding this comment

jpoimboe Oct 26, 2022

Choose a reason for hiding this comment

swine commented Nov 3, 2022 via email

swine commented Sep 15, 2022 •

edited

Loading

t-msn commented Sep 23, 2022 •

edited

Loading

ryncsn Jan 16, 2023 •

edited

Loading