Without this patch, module init sections are disabled by patching their
names in arch-specific code when they're loaded (which prevents code in
layout_sections from finding init sections). This patch uses the new
arch-specific module_init_section instead.
This allows modules that have .init_array sections to have the
initialisers properly called (on load, before init). Without this patch,
the initialisers are not called because .init_array is renamed to
_init_array, and thus isn't found by code in find_module_sections().
Signed-off-by: Wedson Almeida Filho <[email protected]>
---
arch/powerpc/kernel/module_64.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 5d77d3f5fbb5..6a45e6ddbe58 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -277,6 +277,12 @@ static Elf64_Sym *find_dot_toc(Elf64_Shdr *sechdrs,
return NULL;
}
+bool module_init_section(const char *name)
+{
+ /* We don't handle .init for the moment: always return false. */
+ return false;
+}
+
int module_frob_arch_sections(Elf64_Ehdr *hdr,
Elf64_Shdr *sechdrs,
char *secstrings,
@@ -286,7 +292,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
/* Find .toc and .stubs sections, symtab and strtab */
for (i = 1; i < hdr->e_shnum; i++) {
- char *p;
if (strcmp(secstrings + sechdrs[i].sh_name, ".stubs") == 0)
me->arch.stubs_section = i;
else if (strcmp(secstrings + sechdrs[i].sh_name, ".toc") == 0) {
@@ -298,10 +303,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
dedotify_versions((void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size);
- /* We don't handle .init for the moment: rename to _init */
- while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init")))
- p[0] = '_';
-
if (sechdrs[i].sh_type == SHT_SYMTAB)
dedotify((void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf64_Sym),
--
2.35.0.rc2.247.g8bbb082509-goog
Hi Michael,
On Wed, 2 Feb 2022 at 05:53, Wedson Almeida Filho <[email protected]> wrote:
>
> Without this patch, module init sections are disabled by patching their
> names in arch-specific code when they're loaded (which prevents code in
> layout_sections from finding init sections). This patch uses the new
> arch-specific module_init_section instead.
>
> This allows modules that have .init_array sections to have the
> initialisers properly called (on load, before init). Without this patch,
> the initialisers are not called because .init_array is renamed to
> _init_array, and thus isn't found by code in find_module_sections().
>
> Signed-off-by: Wedson Almeida Filho <[email protected]>
> ---
> arch/powerpc/kernel/module_64.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index 5d77d3f5fbb5..6a45e6ddbe58 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -277,6 +277,12 @@ static Elf64_Sym *find_dot_toc(Elf64_Shdr *sechdrs,
> return NULL;
> }
>
> +bool module_init_section(const char *name)
> +{
> + /* We don't handle .init for the moment: always return false. */
> + return false;
> +}
> +
> int module_frob_arch_sections(Elf64_Ehdr *hdr,
> Elf64_Shdr *sechdrs,
> char *secstrings,
> @@ -286,7 +292,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
>
> /* Find .toc and .stubs sections, symtab and strtab */
> for (i = 1; i < hdr->e_shnum; i++) {
> - char *p;
> if (strcmp(secstrings + sechdrs[i].sh_name, ".stubs") == 0)
> me->arch.stubs_section = i;
> else if (strcmp(secstrings + sechdrs[i].sh_name, ".toc") == 0) {
> @@ -298,10 +303,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
> dedotify_versions((void *)hdr + sechdrs[i].sh_offset,
> sechdrs[i].sh_size);
>
> - /* We don't handle .init for the moment: rename to _init */
> - while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init")))
> - p[0] = '_';
> -
> if (sechdrs[i].sh_type == SHT_SYMTAB)
> dedotify((void *)hdr + sechdrs[i].sh_offset,
> sechdrs[i].sh_size / sizeof(Elf64_Sym),
> --
> 2.35.0.rc2.247.g8bbb082509-goog
Would any additional clarification from my part be helpful here?
I got an email saying it was under review (and checks passed) but
nothing appears to have happened since.
Cheers,
-Wedson
On Wed, 2 Feb 2022 05:51:23 +0000, Wedson Almeida Filho wrote:
> Without this patch, module init sections are disabled by patching their
> names in arch-specific code when they're loaded (which prevents code in
> layout_sections from finding init sections). This patch uses the new
> arch-specific module_init_section instead.
>
> This allows modules that have .init_array sections to have the
> initialisers properly called (on load, before init). Without this patch,
> the initialisers are not called because .init_array is renamed to
> _init_array, and thus isn't found by code in find_module_sections().
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/module_64: use module_init_section instead of patching names
https://git.kernel.org/powerpc/c/d4be60fe66b7380530868ceebe549f8eebccacc5
cheers
Wedson Almeida Filho <[email protected]> writes:
> Hi Michael,
>
> On Wed, 2 Feb 2022 at 05:53, Wedson Almeida Filho <[email protected]> wrote:
>>
>> Without this patch, module init sections are disabled by patching their
>> names in arch-specific code when they're loaded (which prevents code in
>> layout_sections from finding init sections). This patch uses the new
>> arch-specific module_init_section instead.
>>
>> This allows modules that have .init_array sections to have the
>> initialisers properly called (on load, before init). Without this patch,
>> the initialisers are not called because .init_array is renamed to
>> _init_array, and thus isn't found by code in find_module_sections().
>>
>> Signed-off-by: Wedson Almeida Filho <[email protected]>
>> ---
>> arch/powerpc/kernel/module_64.c | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
...
>
> Would any additional clarification from my part be helpful here?
Just more patience ;)
> I got an email saying it was under review (and checks passed) but
> nothing appears to have happened since.
I actually put it in next late last week, but the emails got delayed due
to various gremlins.
cheers