From: Miroslav Benes <mbenes@suse.cz>
To: rusty@rustcorp.com.au
Cc: linux-kernel@vger.kernel.org, Miroslav Benes <mbenes@suse.cz>
Subject: [PATCH] module: keep percpu symbols in module's symtab
Date: Fri, 20 Nov 2015 13:54:03 +0100 [thread overview]
Message-ID: <1448024043-29578-1-git-send-email-mbenes@suse.cz> (raw)
Currently, percpu symbols from .data..percpu ELF section of a module are
not copied over and stored in final symtab array of struct module.
Consequently such symbol cannot be returned via kallsyms API (for
example kallsyms_lookup_name). This can be especially confusing when the
percpu symbol is exported. Only its __ksymtab et al. are present in its
symtab.
The culprit is in layout_and_allocate() function where SHF_ALLOC flag is
dropped for .data..percpu section. There is in fact no need to copy the
section to final struct module, because kernel module loader allocates
extra percpu section by itself. Unfortunately only symbols from
SHF_ALLOC sections are copied (see is_core_symbol()).
The patch restores SHF_ALLOC flag for original percpu section. The
section with its symbols is thus copied over, but not otherwise used.
st_value of percpu symbols points to correct newly allocated section
thanks to correction in simplify_symbols().
Signed-off-by: Miroslav Benes <mbenes@suse.cz>
---
I don't deem the solution nice. The other one I came up with was to hack
is_core_symbol() to copy percpu symbols. There is a catch though.
Elf_Sym's st_shndx is an index to an associated section. If we do not
preserve .data..percpu section the index would be invalid. But this is
similar to other symbols as well I guess. The index is never valid after
move_module(), right? The only relevant check I found in the kernel is
in get_ksymbol() - 'st_shndx == SHN_UNDEF'. So it could be harmless.
On the other hand copying of percpu section is simple and should not
break anything.
What do you think?
Thanks,
Miroslav
kernel/module.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 8f051a106676..e489cd7a8d53 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3108,9 +3108,6 @@ static struct module *layout_and_allocate(struct load_info *info, int flags)
if (err < 0)
return ERR_PTR(err);
- /* We will do a special allocation for per-cpu sections later. */
- info->sechdrs[info->index.pcpu].sh_flags &= ~(unsigned long)SHF_ALLOC;
-
/* Determine total sizes, and put offsets in sh_entsize. For now
this is done generically; there doesn't appear to be any
special cases for the architectures. */
--
2.1.4
next reply other threads:[~2015-11-20 12:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-20 12:54 Miroslav Benes [this message]
2015-11-25 1:39 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1448024043-29578-1-git-send-email-mbenes@suse.cz \
--to=mbenes@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®