Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162757AbbKTMyU (ORCPT ); Fri, 20 Nov 2015 07:54:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:37962 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162003AbbKTMyT (ORCPT ); Fri, 20 Nov 2015 07:54:19 -0500 From: Miroslav Benes To: rusty@rustcorp.com.au Cc: linux-kernel@vger.kernel.org, Miroslav Benes Subject: [PATCH] module: keep percpu symbols in module's symtab Date: Fri, 20 Nov 2015 13:54:03 +0100 Message-Id: <1448024043-29578-1-git-send-email-mbenes@suse.cz> X-Mailer: git-send-email 2.1.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2519 Lines: 62 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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/