Different Relocation Handling for Function Pointers between LLVM and GCC in ARM32

[PuzzleZz]

After switching to LLVM, we noticed different behavior in handling relocations, specifically for function pointer relocations. Here's a detailed example:

// Function definition and notifier block setup  
static int lkp_module_notifier(struct notifier_block *nb, unsigned long event, void *data)  
{  
    printk(KERN_ERR "this is lkp_module_notifier call\n");  
    return NOTIFY_OK;  
}  

static struct notifier_block lkp_nb = {  
    .notifier_call  = lkp_module_notifier,  
    .priority = 2,  
};  

LLVM's relocation handling for lkp_module_notifier:

Relocation section '.rel.data.lkp_nb' at offset 0x126c contains 1 entries:  
 Offset     Info    Type                Sym. Value  Symbol's Name  
00000000  00001802 R_ARM_ABS32            00000000   .text.lkp_module_notifier  

Corresponding section content:  
Hex dump of section '.data.lkp_nb':  
0x00000000 04000000 00000000 02000000          ............  

GCC's relocation handling for lkp_module_notifier:

Relocation section '.rel.data.lkp_nb' at offset 0x15b2c contains 1 entry:  
 Offset     Info    Type            Sym.Value  Sym. Name  
00000000  00000702 R_ARM_ABS32       00000004   lkp_module_notifier  

Corresponding section content:  
Hex dump of section '.data.lkp_nb':  
NOTE: This section has relocations against it, but these have NOT been applied to this dump.  
0x00000000 00000000 00000000 02000000          ............  

However, our kpatch tool processes relocations following the GCC format:

Relocation section '.rel.data.lkp_nb' at offset 0x52c contains 1 entries:  
 Offset     Info    Type                Sym. Value  Symbol's Name  
00000000  00000202 R_ARM_ABS32            00000004   lkp_module_notifier  

Corresponding section content:  
Hex dump of section '.data.lkp_nb':  
0x00000000 04000000 00000000 02000000          ............  

LLVM uses section symbol (.text.lkp_module_notifier) for relocation
GCC uses direct function symbol (lkp_module_notifier)
Our kpatch tool expects GCC-style relocations

[PuzzleZz]

I have located the root cause of this issue.

kernel's apply_relocate function processes relocations in the following sequence:

loc = dstsec->sh_addr + rel->r_offset;  

case R_ARM_ABS32:  
case R_ARM_TARGET1:  
    *(u32 *)loc += sym->st_value;  
    break;  

After switching to LLVM compiler, there's a significant change in how function pointer relocations are handled:

LLVM's approach:

Relocation entry:  
- Symbol: .text.lkp_module_notifier  
- Sym.Value: 0x00000000  
- Section content: 0x04000000 (4)  

Final address = section_content + sym.value  
              = 4 + 0 = 4  

GCC's approach:

Relocation entry:  
- Symbol: lkp_module_notifier  
- Sym.Value: 0x00000004 (4)  
- Section content: 0x00000000 (0)  

Final address = section_content + sym.value  
              = 0 + 4 = 4  

Current kpatch tool's processing (problematic):

Relocation entry:  
- Symbol: lkp_module_notifier  
- Sym.Value: 0x00000004 (4)  
- Section content: 0x04000000 (4)  

Final address = section_content + sym.value  
              = 4 + 4 = 8  // Incorrect! Double-counting the offset 

The issue is that kpatch is not properly handling the compiler-specific differences:

LLVM stores the offset in the section content (4) with sym.value = 0
GCC stores the offset in sym.value (4) with section content = 0
But kpatch is ending up with both values set to 4, causing the function pointer to point to offset 8 instead of 4
This explains why we need to skip symbol replacement for function pointer relocations in .data sections when using LLVM - it prevents this double-counting of the offset value and maintains the correct function pointer address calculation.

[PuzzleZz]

I have adapted the kpatch code in the kpatch_replace_sections_syms function within create-diff-object.c. The solution is to skip symbol replacement when detecting function pointer relocations. This effectively resolves the issue.

Here's the detailed patch:

From: Zhou Siqi <[email protected]>  
Date: Tue, 18 Feb 2025 19:03:29 +0800  
Subject: [PATCH] kpatch: adapting llvm special relocation  

After switching to LLVM compiler, there's a significant change in how function   
pointer relocations are handled:  

Under GNU toolchain:  
- Uses direct function symbol for relocation  
- Example: lkp_module_notifier + 0  
- Relocation type is R_ARM_ABS32, pointing directly to the function symbol  

Under LLVM toolchain:  
- Uses code section for relocation instead of function symbol  
- Example: .text.lkp_module_notifier + 4  
- Relocation points to the function's code section (with .text. prefix)   
  rather than the symbol itself  

Signed-off-by: Zhou Siqi <[email protected]>  
---  
 kpatch-build/create-diff-object.c | 11 +++++++++++  
 1 file changed, 11 insertions(+)  

diff --git a/kpatch-build/create-diff-object.c b/kpatch-build/create-diff-object.c  
index aaf46fe..d008f42 100644  
--- a/kpatch-build/create-diff-object.c  
+++ b/kpatch-build/create-diff-object.c  
@@ -1745,6 +1745,17 @@ static void kpatch_replace_sections_syms(struct kpatch_elf *kelf)  
                                continue;  

                        /*  
+                         * Handle compiler-specific relocation differences for function pointers:  
+                         * - GNU: uses direct function symbol in .data section (lkp_module_notifier + 0)  
+                         * - LLVM: uses section symbol in .data section (.text.lkp_module_notifier + 4)  
+                         *  
+                         * For function pointer relocations in .data sections, skip symbol replacement  
+                         * when using LLVM to maintain correct references to function symbols.  
+                         */  
+                        if (rela->sym->name && !strncmp(sec->base->name, ".data.", 6))  
+                                continue;  
+  
+                        /*  
                          * Replace references to bundled sections with their  
                          * symbols.  
                          */  
--   
2.12.3  

The key change is adding a check to skip symbol replacement for relocations in .data sections, which handles the LLVM-specific function pointer relocation case while maintaining compatibility with GNU-style relocations.

[joe-lawrence]

Hi @PuzzleZz thanks for the detailed report!

Disclaimer: upstream kpatch doesn't currently support ARM32 and llvm is currently a best-effort. But the reported behavior is nonetheless interesting to learn. Do you know if llvm/ARM64 is similarly affected? Can you share which kpatch fork and kernel changes that you are running with? And finally, is the presence of the code (provided in the first comment) in a kpatch sufficient enough to hit this issue? Thanks.

[PuzzleZz]

Hi @joe-lawrence

Do you know if llvm/ARM64 is similarly affected?

ARM64 Has Similar Relocation Changes with LLVM

After switching to LLVM on ARM64, we observe similar relocation behavior changes:

LLVM patched/xx.o:  
Relocation section '.rela.data.lkp_nb' at offset 0x1780 contains 1 entries:  
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend  
0000000000000000  0000001300000101 R_AARCH64_ABS64        0000000000000000 .text.lkp_module_notifier + 4  

Section content:  
Hex dump of section '.data.lkp_nb':  
0x00000000 00000000 00000000 00000000 00000000 ................  
0x00000010 02000000 00000000                   ........  

LLVM output/xx.o (after kpatch create-diff-object processing):  
Relocation section '.rela.data.lkp_nb' at offset 0x6a8 contains 1 entries:  
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend  
0000000000000000  0000000200000101 R_AARCH64_ABS64        0000000000000004 lkp_module_notifier + 0  

Section content:  
Hex dump of section '.data.lkp_nb':  
0x00000000 00000000 00000000 00000000 00000000 ................  
0x00000010 02000000 00000000   

While the kpatch functionality currently works because the section content is 0 in both cases (resulting in the same final address calculation), I believe we should maintain LLVM's relocation format to prevent potential future issues.

Can you share which kpatch fork and kernel changes that you are running with?

I've only adapted the kpatch tools for LLVM compilation. For reference, we're using:
Kernel version: 5.10
LLVM version: 15.0.4

Finally.Here's how to reproduce the issue using a kernel module hot patch:
Original code:

#include <linux/module.h>  
#include <linux/kernel.h>  
#include <linux/init.h>  
#include <linux/delay.h>  
   
void run(void)  
{  
    printk(KERN_INFO "Hello World ... \n");  
}  

static int hello_init(void)  
{  
    run();  
    return 0;  
}  
   
static void bye_exit(void)  
{  
    printk(KERN_INFO "bye bye.\n");  
    return;  
}  

module_init(hello_init);  
module_exit(bye_exit);  
MODULE_LICENSE("GPL");

Patch file:

diff --git a/kpatch_hook.c b/kpatch_hook.c  
index eceb8db..3b146c8 100644  
--- a/kpatch_hook.c  
+++ b/kpatch_hook.c  
@@ -20,6 +20,34 @@ static void bye_exit(void)  
     return;  
 }  

+#include <asm/cacheflush.h>  
+// Added static function lkp_module_notifier used only as function pointer  
+static int lkp_module_notifier(struct notifier_block *nb, unsigned long event, void *data)  
+{  
+    printk(KERN_ERR "this is lkp_module_notifier call\n");  
+    return NOTIFY_OK;  
+}  
+  
+static struct notifier_block lkp_nb = {  
+    .notifier_call  = lkp_module_notifier,  
+    .priority = 2,  
+};  
+  
+void hook_test_load(void)  
+{  
+    register_module_notifier(&lkp_nb);  
+    printk(KERN_ERR "register lkp_module_notifier success in hook_test_load!\n");  
+}  
+  
+void hook_test_unload(void)  
+{  
+    unregister_module_notifier(&lkp_nb);  
+    printk(KERN_ERR "unregister lkp_module_notifier success in hook_test_load!\n");  
+}  
+#include "kpatch-macros.h"  
+KPATCH_LOAD_HOOK(hook_test_load);  
+KPATCH_UNLOAD_HOOK(hook_test_unload);  
+  
 module_init(hello_init);  
 module_exit(bye_exit);  
 MODULE_LICENSE("GPL");  

To reproduce:

1.The patch registers a hook function that triggers lkp_module_notifier when kernel module changes occur
2.Prepare another kernel module
3.Execute insmod with the second module to trigger the issue

[joe-lawrence]

Without arm32 (or 64) support in this project, I can't really reproduce it and when I look at non-kpatch module builds on x86/arm64 using both gcc/llvm, I see the same section-based relocations for pointers to local functions, and direct symbol relocations for global functions. This was using gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7) and clang version 19.1.7 (Red Hat, Inc. 19.1.7-2.el10) on both arches. Perhaps other versions generate things differently?

(Also, to clarify the report, can you identify which object file is dumped? I understand the report as the compilers generating two different kinds of relocations for the patched .o file and then kpatch-build's rela mangling screws up the section-based one in the output.o file.)

Finally which fork of kpatch-build are you using that has this support (git remote get-url origin). Could it be one of these?

• https://gitee.com/anolis/kpatch-build
• https://gitee.com/src-openeuler/kpatch

Perhaps they have encountered this?

@puranjaymohan , @liu-song-6 : have you seen this behavior in your kpatch for ARM64 experiences?

[PuzzleZz]

Let me clarify this issue more thoroughly.

Summary of the Problem:
GCC and LLVM handle function pointer relocations differently. The kpatch tool's create-diff-object, specifically in the kpatch_replace_sections_syms function, converts section-based relocations to symbol-based relocations. Since GCC naturally uses symbol-based relocations for function pointers, this conversion doesn't affect GCC scenarios. However, LLVM relies on section-based relocations for function pointers, where the base section content has a value (as mentioned earlier, Section content: 0x04000000). Converting this to symbol-based relocation leads to issues.

My proposed patch solution identifies these scenarios and skips forcing them into the GCC format.

Here's a simple kernel module to demonstrate the GCC vs LLVM differences:

#include <linux/module.h>  
#include <linux/kernel.h>  
#include <linux/init.h>  
#include <linux/delay.h>  
#include <asm/cacheflush.h>  

static int lkp_module_notifier(struct notifier_block *nb, unsigned long event, void *data)  
{  
    printk(KERN_ERR "call lkp_module_notifier success\n");  
    return NOTIFY_OK;  
}  

static struct notifier_block lkp_nb = {  
    .notifier_call  = lkp_module_notifier,  
    .priority = 2,  
};  

void run(void)  
{  
    printk(KERN_ERR "Hello this is lkp_nb test ... \n");  
}  

static int hello_init(void)  
{  
    run();  
    register_module_notifier(&lkp_nb);  
    return 0;  
}  

static void bye_exit(void)  
{  
    printk(KERN_ERR "bye bye.\n");  
    unregister_module_notifier(&lkp_nb);  
    return;  
}  

module_init(hello_init);  
module_exit(bye_exit);  
MODULE_LICENSE("GPL");  

obj-m := kpatch_hook.o  

PWD := $(shell pwd)  

ifndef DL_SDK_KERNELDIR  
        DL_SDK_KERNELDIR=$(KERNEL_SRC)  
endif  

EXTRA_CFLAGS += -ffunction-sections -fdata-sections -fno-align-functions  

all:  
        $(MAKE) -C $(DL_SDK_KERNELDIR) M=$(PWD) ARCH=$(ARCH) modules  
clean:  
        $(MAKE) -C $(DL_SDK_KERNELDIR) M=$(PWD) ARCH=$(ARCH) clean  

GCC output:

arm32-linux-gnueabi-readelf -r kpatch_hook.ko > klp.r  

Relocation section '.rel.data.lkp_nb' at offset 0x1e00c contains 1 entry:  
 Offset     Info    Type            Sym.Value  Sym. Name  
00000000  00002802 R_ARM_ABS32       00000004   lkp_module_notifier  

arm32-linux-gnueabi-readelf -x .data.lkp_nb kpatch_hook.ko   

Hex dump of section '.data.lkp_nb':  
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.  
  0x00000000 00000000 00000000 02000000          ............ 

LLVM output:

arm32-linux-llvm-readelf -r kpatch_hook.ko > klp.r  

Relocation section '.rel.data.lkp_nb' at offset 0x60e0 contains 1 entries:  
 Offset     Info    Type                Sym. Value  Symbol's Name  
00000000  00000702 R_ARM_ABS32            00000000   .text.lkp_module_notifier  

arm32-linux-llvm-readelf -x .data.lkp_nb kpatch_hook.ko  
Hex dump of section '.data.lkp_nb':  
0x00000000 04000000 00000000 02000000          ............

As shown in these results, there's a clear difference in how GCC and LLVM handle function pointer relocations. For LLVM-compiled scenarios, it's best to adapt the kpatch_replace_sections_syms function to handle these cases by not performing the replacement.

You can try to reproduce this issue using the tools maintained in this repository:
https://gitee.com/src-openeuler/kpatch
Note that we've made many additional adaptations to this codebase for our use case.

[joe-lawrence]

Thanks for hanging with me @PuzzleZz :) here are some things that I think I've learned today:

• Only gcc on Arm(32) is generating symbol-based relocations

Using your kpatch_hook.c example, I built the example module for Arm, Arm64, and x86_64 using both llvm and gcc. The only combination that generated a symbol based relocation lkp_module_notifier was gcc on Arm(32):

== gcc-arm64-kpatch_hook.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped
Relocation section '.rela.data.lkp_nb' at offset 0x4928 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000000000  0000000700000101 R_AARCH64_ABS64        0000000000000000 .text.unlikely.lkp_module_notifier + 8

Hex dump of section '.data.lkp_nb':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000 00000000 00000000 00000000 ................
  0x00000010 02000000 00000000                   ........


== gcc-arm-kpatch_hook.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
Relocation section '.rel.data.lkp_nb' at offset 0x714 contains 1 entry:
 Offset     Info    Type                Sym. Value  Symbol's Name
00000000  00000a02 R_ARM_ABS32            00000000   lkp_module_notifier

Hex dump of section '.data.lkp_nb':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000 00000000 02000000          ............


== gcc-x86_64-kpatch_hook.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
Relocation section '.rela.data.lkp_nb' at offset 0x6e8 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000000000  0000000300000001 R_X86_64_64            0000000000000000 .text.unlikely.lkp_module_notifier + 10

Hex dump of section '.data.lkp_nb':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000 00000000 00000000 00000000 ................
  0x00000010 02000000 00000000                   ........


== llvm-arm64-kpatch_hook.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped
Relocation section '.rela.data.lkp_nb' at offset 0x1820 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000000000  0000001000000101 R_AARCH64_ABS64        0000000000000000 .text.lkp_module_notifier + 8
readelf: llvm-arm64-kpatch_hook.o: Warning: Unrecognized form: 0x23

Hex dump of section '.data.lkp_nb':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000 00000000 00000000 00000000 ................
  0x00000010 02000000 00000000                   ........


== llvm-arm-kpatch_hook.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
Relocation section '.rel.data.lkp_nb' at offset 0x40c contains 1 entry:
 Offset     Info    Type                Sym. Value  Symbol's Name
00000000  00000b02 R_ARM_ABS32            00000000   .text.lkp_module_notifier

Hex dump of section '.data.lkp_nb':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000 00000000 02000000          ............


== llvm-x86_64-kpatch_hook.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
Relocation section '.rela.data.lkp_nb' at offset 0x9b8 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000000000  0000000900000001 R_X86_64_64            0000000000000000 .text.lkp_module_notifier + 10
readelf: llvm-x86_64-kpatch_hook.o: Warning: Unrecognized form: 0x23

Hex dump of section '.data.lkp_nb':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000 00000000 00000000 00000000 ................
  0x00000010 02000000 00000000                   ........

That said, if I change lkp_module_notifier from a local to global (ie, removing its static), then all combinations generate a symbol-based relocation lkp_module_notifier of the same relocation type as before. With that in mind, I think we have been successfully handling both relocation cases for existing x86_64, ppc64le and s390x arches.

• Arm relocation addends can be interesting

I've looked at a few architecture specific relocation types: Arm, PowerPC, s390x, and x86_64 and it's interesting that only Arm defines the addend as (italics mine):

A - denotes the addend used to compute the new value of the storage unit being relocated.

• It is the value extracted from the storage unit being relocated (relocation directives of sort SHT_REL) or the sum of that value and the r_addend field of the relocation directive (sort SHT_RELA).
• If it has a unit, the unit is bytes. An encoded address or offset value is converted to bytes on extraction from a storage unit and re-encoded on insertion into a storage unit

and sure enough, you highlight that in arch/arm/kernel/module.c :: apply_relocate()'s handling of R_ARM_ABS32:

                case R_ARM_ABS32:
                case R_ARM_TARGET1:
                        *(u32 *)loc += sym->st_value;
                        break;

(Some more reading of the System V Application Binary Interface notes that "Entries of type Elf32_Rel and Elf64_Rel store an implicit addend in the location to be modified." So it's really just a SHT_REL vs. SHT_RELA thing across arches and only the Arm spec reminds us of that.)

I could be wrong, but it seems like all other arches (including Arm64) are generating SHT_RELA for function pointers, so the section contents has never mattered. So even though Arm64 creates R_AARCH64_ABS64, it seems like the symbol value / addend / section content are still consistent. I don't see the same *loc += type logic in arch/arm64/kernel/module.c, so maybe the kernel never encounters the same SHT_REL / R_AARCH64_ABS64 combination?

• My relocation symbol values and section content are always zero

From my readelf output pasted above, in all of my cases both the symbol value and section content are zero. I'm not sure why or how to force a different value in either. Perhaps your kernel configuration would help me reproduce that?

• Fixing kpatch-build

The proposed patch short circuits kpatch_replace_sections_syms() for any ".data." section regardless of the compiler, relocation types, or architecture. Does imply that they never needed mangling in the first place? (See the comment above the function, "substitute the object/function symbols for the section symbol in this case so that the relas can be properly correlated and so that the existing object/function in vmlinux can be linked to.")

Instead of skipping them, would it make sense to fix the mangling, so that it accounts to for these type of relocations that depend on the section contents?

kmod.tar.gz

[wardenjohn]

@PuzzleZz FYI, I had detected a problem under ARM64 of kpatch.

On kernel-6.6 aarch64, kpatch-build will have ld issue that '__patchable_function_entries' have both ordered and unordered issues, which will make ld process die. This problem I am still working on it.

I dont know if you had met this problem before, or something related with this issue.

As the email I had sent you before. @joe-lawrence

[joe-lawrence]

@wardenjohn : I have not encountered that linker problem in my relatively small Arm experiences nor PowerPC 64 (for which RHEL-10 config will use __patchable_function_entries as well). I think you will have better luck over on the #1439 thread (are you testing with this branch?) than here, as #1441 is strictly about function pointer relocation types.

[PuzzleZz]

@joe-lawrence Sorry I've been a bit busy lately and just saw your message. I suspect that the lack of offset in your results is because you haven't enabled forward CFI. We will enable this feature and insert 4 bytes of checksum information at the beginning of each function. So, I suspect this offset is introduced here.
I previously added some debug prints before generating the patch to see which relocations would be converted, and I did not observe any relocations with a base section of .data; they were mainly from the .text section. Could you help analyze the purpose of kpatch_replace_sections_syms in performing relocation replacements?
I have integrated the patch I provided into our code repository, and after half a month, I have not noticed any abnormalities.

[wardenjohn]

@joe-lawrence I think you can try gcc version:
gcc version 12.2.1 20221121 (Red Hat 12.2.1-7)
GNU ld version 2.38-17

[wardenjohn]

@joe-lawrence
Function test well base on the branch #1439 🥺 . There maybe some mistakes in my code. Let me check again....😭...
Thanks for your remind 🙏

[joe-lawrence]

@PuzzleZz : no worries, investigating this is rather time intensive on my part as I have to setup cross compilers and pick through a completely new architecture (to me).

I haven't made much progress from my last comment, other than enabling CONFIG_CFI_CLANG for an llvm Arm(32) build of a similar function-pointer test module:

Relocation section '.rel.data.data_local_function' at offset 0x3d8 contains 1 entry:
 Offset     Info    Type                Sym. Value  Symbol's Name
00000000  00000802 R_ARM_ABS32            00000000   .text.lfunction

Hex dump of section '.data.data_local_function':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 04000000                            ...


Relocation section '.rel.data.data_global_function' at offset 0x3e0 contains 1 entry:
 Offset     Info    Type                Sym. Value  Symbol's Name
00000000  00001402 R_ARM_ABS32            00000004   gfunction

Hex dump of section '.data.data_global_function':
 NOTE: This section has relocations against it, but these have NOT been applied to this dump.
  0x00000000 00000000                            ....

which I think finally reproduces the original report, right (for pointers to locally scoped functions)?

Anyway, I'm hesitant to change this singular function to handle what I believe is a SHT_REL vs. SHT_RELA issue when I think the rest of the code base assumes SHT_RELA as it's only been coded for 64-bit arches (which don't seem to use SHT_REL in most kernel objects).

I'll keep poking at it, but in the meantime, someone like @jpoimboe would be more knowledgeable about the relocations and whether mangling / normalizing function pointer relocations really matter for "correlation and linking to vmlinux" as the code comments imply.

[github-actions]

This issue has been open for 30 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

[github-actions]

This issue was closed because it was inactive for 7 days after being marked stale.