2019-10-10 15:16:43

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces

The introduction of the symbol namespace patches changed the way symbols are
named in the ksymtab entries. That caused userland tools to fail (such as
kmod's depmod). As depmod is used as part of the kernel build it was worth
having another look whether this name change can be avoided.

The main purpose of this series is to restore the original ksymtab entry names.
For that to happen and to remove some rough edges around that, the relevant
parts in modpost got a small refactoring as to when and how namespaces are
evaluated and set in the symbol struct.

Eventually, the namespace values can be read from __kstrtabns_ entries and
their corresponding __ksymtab_strings values. That removes the need to carry
the namespace names within the (anyway unique) symbol name entries.

The last patch of this series is adopted from Masahiro [1]. By allowing 'no
namespace' to be represented as empty string, large chunks of
include/linux/export.h could be consolidated. Technically, this last patch is
not absolutely necessary to fix functionality. It addresses concerns about
maintainability and readability. While I strongly suggest sending all of the
patches for 5.4, the last one could possible deferred to the next merge window.

This patch applies to the modules-linus [2] branch.

[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git/log/?h=modules-linus

Cc: Jessica Yu <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Martijn Coenen <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Shaun Ruffell <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Cc: [email protected]


Matthias Maennich (4):
modpost: delegate updating namespaces to separate function
modpost: make updating the symbol namespace explict
symbol namespaces: revert to previous __ksymtab name scheme
export: avoid code duplication in include/linux/export.h

include/linux/export.h | 97 +++++++++++++-----------------------------
kernel/module.c | 2 +-
scripts/mod/modpost.c | 58 ++++++++++++++++---------
scripts/mod/modpost.h | 1 +
4 files changed, 69 insertions(+), 89 deletions(-)

--
2.23.0.581.g78d2f28ef7-goog


2019-10-10 15:16:45

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH 1/4] modpost: delegate updating namespaces to separate function

Let the function 'sym_update_namespace' take care of updating the
namespace for a symbol. While this currently only replaces one single
location where namespaces are updated, in a following patch, this
function will get more call sites.

The function signature is intentionally close to sym_update_crc and
taking the name by char* seems like unnecessary work as the symbol has
to be looked up again. In a later patch of this series, this concern
will be addressed.

This function ensures that symbol::namespace is either NULL or has a
valid non-empty value. Previously, the empty string was considered 'no
namespace' as well and this lead to confusion.

Signed-off-by: Matthias Maennich <[email protected]>
---
scripts/mod/modpost.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 4d2cdb4d71e3..9f5dcdff4d2f 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -362,6 +362,22 @@ static char *sym_extract_namespace(const char **symname)
return namespace;
}

+static void sym_update_namespace(const char *symname, const char *namespace)
+{
+ struct symbol *s = find_symbol(symname);
+ /* That symbol should have been created earlier and thus this is
+ * actually an assertion. */
+ if (!s) {
+ merror("Could not update namespace(%s) for symbol %s\n",
+ namespace, symname);
+ return;
+ }
+
+ free(s->namespace);
+ s->namespace =
+ namespace && namespace[0] ? NOFAIL(strdup(namespace)) : NULL;
+}
+
/**
* Add an exported symbol - it may have already been added without a
* CRC, in this case just update the CRC
@@ -383,8 +399,7 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,
s->module = mod;
}
}
- free(s->namespace);
- s->namespace = namespace ? strdup(namespace) : NULL;
+ sym_update_namespace(name, namespace);
s->preloaded = 0;
s->vmlinux = is_vmlinux(mod->name);
s->kernel = 0;
@@ -2196,7 +2211,7 @@ static int check_exports(struct module *mod)
else
basename = mod->name;

- if (exp->namespace && exp->namespace[0]) {
+ if (exp->namespace) {
add_namespace(&mod->required_namespaces,
exp->namespace);

--
2.23.0.581.g78d2f28ef7-goog

2019-10-10 15:16:53

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH 2/4] modpost: make updating the symbol namespace explict

Setting the symbol namespace of a symbol within sym_add_exported feels
displaced and lead to issues in the current implementation of symbol
namespaces. This patch makes updating the namespace an explicit call to
decouple it from adding a symbol to the export list.

Signed-off-by: Matthias Maennich <[email protected]>
---
scripts/mod/modpost.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 9f5dcdff4d2f..46137b730447 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -382,8 +382,8 @@ static void sym_update_namespace(const char *symname, const char *namespace)
* Add an exported symbol - it may have already been added without a
* CRC, in this case just update the CRC
**/
-static struct symbol *sym_add_exported(const char *name, const char *namespace,
- struct module *mod, enum export export)
+static struct symbol *sym_add_exported(const char *name, struct module *mod,
+ enum export export)
{
struct symbol *s = find_symbol(name);

@@ -399,7 +399,6 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,
s->module = mod;
}
}
- sym_update_namespace(name, namespace);
s->preloaded = 0;
s->vmlinux = is_vmlinux(mod->name);
s->kernel = 0;
@@ -761,7 +760,8 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
if (strstarts(symname, "__ksymtab_")) {
name = symname + strlen("__ksymtab_");
namespace = sym_extract_namespace(&name);
- sym_add_exported(name, namespace, mod, export);
+ sym_add_exported(name, mod, export);
+ sym_update_namespace(name, namespace);
free(namespace);
}
if (strcmp(symname, "init_module") == 0)
@@ -2469,12 +2469,12 @@ static void read_dump(const char *fname, unsigned int kernel)
mod = new_module(modname);
mod->skip = 1;
}
- s = sym_add_exported(symname, namespace, mod,
- export_no(export));
+ s = sym_add_exported(symname, mod, export_no(export));
s->kernel = kernel;
s->preloaded = 1;
s->is_static = 0;
sym_update_crc(symname, mod, crc, export_no(export));
+ sym_update_namespace(symname, namespace);
}
release_file(file, size);
return;
--
2.23.0.581.g78d2f28ef7-goog

2019-10-10 15:17:00

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH 3/4] symbol namespaces: revert to previous __ksymtab name scheme

The introduction Symbol Namespaces changed the naming schema of the
__ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol.

That caused some breakages in tools that depend on the name layout in
either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod
would not be able to read System.map without a patch to support symbol
namespaces. A warning reported by depmod for namespaced symbols would
look like

depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks

In order to address this issue, revert to the original naming scheme and
rather read the __kstrtabns_<symbol> entries and their corresponding
values from __ksymtab_strings to update the namespace values for
symbols. After having read all symbols and handled them in
handle_modversions(), the symbols are created. In a second pass, read
the __kstrtabns_ entries and update the namespaces accordingly.

Suggested-by: Jessica Yu <[email protected]>
Fixes: 8651ec01daed ("module: add support for symbol namespaces.")
Signed-off-by: Matthias Maennich <[email protected]>
---
include/linux/export.h | 13 +++++--------
scripts/mod/modpost.c | 33 ++++++++++++++++++---------------
scripts/mod/modpost.h | 1 +
3 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/include/linux/export.h b/include/linux/export.h
index 621158ecd2e2..f24b86d7dd4d 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -18,8 +18,6 @@ extern struct module __this_module;
#define THIS_MODULE ((struct module *)0)
#endif

-#define NS_SEPARATOR "."
-
#ifdef CONFIG_MODVERSIONS
/* Mark the CRC weak since genksyms apparently decides not to
* generate a checksums for some symbols */
@@ -48,11 +46,11 @@ extern struct module __this_module;
* absolute relocations that require runtime processing on relocatable
* kernels.
*/
-#define __KSYMTAB_ENTRY_NS(sym, sec, ns) \
+#define __KSYMTAB_ENTRY_NS(sym, sec) \
__ADDRESSABLE(sym) \
asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
" .balign 4 \n" \
- "__ksymtab_" #ns NS_SEPARATOR #sym ": \n" \
+ "__ksymtab_" #sym ": \n" \
" .long " #sym "- . \n" \
" .long __kstrtab_" #sym "- . \n" \
" .long __kstrtabns_" #sym "- . \n" \
@@ -74,9 +72,8 @@ struct kernel_symbol {
int namespace_offset;
};
#else
-#define __KSYMTAB_ENTRY_NS(sym, sec, ns) \
- static const struct kernel_symbol __ksymtab_##sym##__##ns \
- asm("__ksymtab_" #ns NS_SEPARATOR #sym) \
+#define __KSYMTAB_ENTRY_NS(sym, sec) \
+ static const struct kernel_symbol __ksymtab_##sym \
__attribute__((section("___ksymtab" sec "+" #sym), used)) \
__aligned(sizeof(void *)) \
= { (unsigned long)&sym, __kstrtab_##sym, __kstrtabns_##sym }
@@ -115,7 +112,7 @@ struct kernel_symbol {
static const char __kstrtabns_##sym[] \
__attribute__((section("__ksymtab_strings"), used, aligned(1))) \
= #ns; \
- __KSYMTAB_ENTRY_NS(sym, sec, ns)
+ __KSYMTAB_ENTRY_NS(sym, sec)

#define ___EXPORT_SYMBOL(sym, sec) \
___export_symbol_common(sym, sec); \
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 46137b730447..7cf0065ac95f 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -348,18 +348,11 @@ static enum export export_from_sec(struct elf_info *elf, unsigned int sec)
return export_unknown;
}

-static char *sym_extract_namespace(const char **symname)
+static const char *namespace_from_kstrtabns(struct elf_info *info,
+ Elf_Sym *kstrtabns)
{
- char *namespace = NULL;
- char *ns_separator;
-
- ns_separator = strchr(*symname, '.');
- if (ns_separator) {
- namespace = NOFAIL(strndup(*symname, ns_separator - *symname));
- *symname = ns_separator + 1;
- }
-
- return namespace;
+ char *value = info->ksymtab_strings + kstrtabns->st_value;
+ return value[0] ? value : NULL;
}

static void sym_update_namespace(const char *symname, const char *namespace)
@@ -597,6 +590,10 @@ static int parse_elf(struct elf_info *info, const char *filename)
info->export_unused_gpl_sec = i;
else if (strcmp(secname, "__ksymtab_gpl_future") == 0)
info->export_gpl_future_sec = i;
+ else if (strcmp(secname, "__ksymtab_strings") == 0)
+ info->ksymtab_strings = (void *)hdr +
+ sechdrs[i].sh_offset -
+ sechdrs[i].sh_addr;

if (sechdrs[i].sh_type == SHT_SYMTAB) {
unsigned int sh_link_idx;
@@ -686,7 +683,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
enum export export;
bool is_crc = false;
const char *name;
- char *namespace;

if ((!is_vmlinux(mod->name) || mod->is_dot_o) &&
strstarts(symname, "__ksymtab"))
@@ -759,10 +755,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
/* All exported symbols */
if (strstarts(symname, "__ksymtab_")) {
name = symname + strlen("__ksymtab_");
- namespace = sym_extract_namespace(&name);
sym_add_exported(name, mod, export);
- sym_update_namespace(name, namespace);
- free(namespace);
}
if (strcmp(symname, "init_module") == 0)
mod->has_init = 1;
@@ -2058,6 +2051,16 @@ static void read_symbols(const char *modname)
handle_moddevtable(mod, &info, sym, symname);
}

+ /* Apply symbol namespaces from __kstrtabns_<symbol> entries. */
+ for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
+ symname = remove_dot(info.strtab + sym->st_name);
+
+ if (strstarts(symname, "__kstrtabns_"))
+ sym_update_namespace(symname + strlen("__kstrtabns_"),
+ namespace_from_kstrtabns(&info,
+ sym));
+ }
+
// check for static EXPORT_SYMBOL_* functions && global vars
for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
unsigned char bind = ELF_ST_BIND(sym->st_info);
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 92a926d375d2..ad271bc6c313 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -143,6 +143,7 @@ struct elf_info {
Elf_Section export_gpl_sec;
Elf_Section export_unused_gpl_sec;
Elf_Section export_gpl_future_sec;
+ char *ksymtab_strings;
char *strtab;
char *modinfo;
unsigned int modinfo_len;
--
2.23.0.581.g78d2f28ef7-goog

2019-10-10 15:17:54

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH 4/4] export: avoid code duplication in include/linux/export.h

Now that the namespace value is not part of the __ksymtab entry name
anymore, we can simplify the implementation of EXPORT_SYMBOL*. By
allowing the empty string "" to represent 'no namespace', we can unify
the implementation and drop a lot redundant code. That increases
readability and maintainability.

As Masahiro pointed out earlier,
"The drawback of this change is, it grows the code size. When the symbol
has no namespace, sym->namespace was previously NULL, but it is now am
empty string "". So, it increases 1 byte for every no namespace
EXPORT_SYMBOL. A typical kernel configuration has 10K exported symbols,
so it increases 10KB in rough estimation."

Suggested-by: Masahiro Yamada <[email protected]>
Signed-off-by: Matthias Maennich <[email protected]>
---
include/linux/export.h | 92 +++++++++++++-----------------------------
kernel/module.c | 2 +-
2 files changed, 29 insertions(+), 65 deletions(-)

diff --git a/include/linux/export.h b/include/linux/export.h
index f24b86d7dd4d..201262793369 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -46,7 +46,7 @@ extern struct module __this_module;
* absolute relocations that require runtime processing on relocatable
* kernels.
*/
-#define __KSYMTAB_ENTRY_NS(sym, sec) \
+#define __KSYMTAB_ENTRY(sym, sec) \
__ADDRESSABLE(sym) \
asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
" .balign 4 \n" \
@@ -56,34 +56,17 @@ extern struct module __this_module;
" .long __kstrtabns_" #sym "- . \n" \
" .previous \n")

-#define __KSYMTAB_ENTRY(sym, sec) \
- __ADDRESSABLE(sym) \
- asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
- " .balign 4 \n" \
- "__ksymtab_" #sym ": \n" \
- " .long " #sym "- . \n" \
- " .long __kstrtab_" #sym "- . \n" \
- " .long 0 \n" \
- " .previous \n")
-
struct kernel_symbol {
int value_offset;
int name_offset;
int namespace_offset;
};
#else
-#define __KSYMTAB_ENTRY_NS(sym, sec) \
- static const struct kernel_symbol __ksymtab_##sym \
- __attribute__((section("___ksymtab" sec "+" #sym), used)) \
- __aligned(sizeof(void *)) \
- = { (unsigned long)&sym, __kstrtab_##sym, __kstrtabns_##sym }
-
#define __KSYMTAB_ENTRY(sym, sec) \
static const struct kernel_symbol __ksymtab_##sym \
- asm("__ksymtab_" #sym) \
__attribute__((section("___ksymtab" sec "+" #sym), used)) \
__aligned(sizeof(void *)) \
- = { (unsigned long)&sym, __kstrtab_##sym, NULL }
+ = { (unsigned long)&sym, __kstrtab_##sym, __kstrtabns_##sym }

struct kernel_symbol {
unsigned long value;
@@ -94,28 +77,20 @@ struct kernel_symbol {

#ifdef __GENKSYMS__

-#define ___EXPORT_SYMBOL(sym,sec) __GENKSYMS_EXPORT_SYMBOL(sym)
-#define ___EXPORT_SYMBOL_NS(sym,sec,ns) __GENKSYMS_EXPORT_SYMBOL(sym)
+#define ___EXPORT_SYMBOL(sym, sec, ns) __GENKSYMS_EXPORT_SYMBOL(sym)

#else

-#define ___export_symbol_common(sym, sec) \
+/* For every exported symbol, place a struct in the __ksymtab section */
+#define ___EXPORT_SYMBOL(sym, sec, ns) \
extern typeof(sym) sym; \
__CRC_SYMBOL(sym, sec); \
static const char __kstrtab_##sym[] \
__attribute__((section("__ksymtab_strings"), used, aligned(1))) \
- = #sym \
-
-/* For every exported symbol, place a struct in the __ksymtab section */
-#define ___EXPORT_SYMBOL_NS(sym, sec, ns) \
- ___export_symbol_common(sym, sec); \
+ = #sym; \
static const char __kstrtabns_##sym[] \
__attribute__((section("__ksymtab_strings"), used, aligned(1))) \
- = #ns; \
- __KSYMTAB_ENTRY_NS(sym, sec)
-
-#define ___EXPORT_SYMBOL(sym, sec) \
- ___export_symbol_common(sym, sec); \
+ = ns; \
__KSYMTAB_ENTRY(sym, sec)

#endif
@@ -127,8 +102,7 @@ struct kernel_symbol {
* be reused in other execution contexts such as the UEFI stub or the
* decompressor.
*/
-#define __EXPORT_SYMBOL_NS(sym, sec, ns)
-#define __EXPORT_SYMBOL(sym, sec)
+#define __EXPORT_SYMBOL(sym, sec, ns)

#elif defined(CONFIG_TRIM_UNUSED_KSYMS)

@@ -144,48 +118,38 @@ struct kernel_symbol {
#define __ksym_marker(sym) \
static int __ksym_marker_##sym[0] __section(".discard.ksym") __used

-#define __EXPORT_SYMBOL(sym, sec) \
- __ksym_marker(sym); \
- __cond_export_sym(sym, sec, __is_defined(__KSYM_##sym))
-#define __cond_export_sym(sym, sec, conf) \
- ___cond_export_sym(sym, sec, conf)
-#define ___cond_export_sym(sym, sec, enabled) \
- __cond_export_sym_##enabled(sym, sec)
-#define __cond_export_sym_1(sym, sec) ___EXPORT_SYMBOL(sym, sec)
-#define __cond_export_sym_0(sym, sec) /* nothing */
-
-#define __EXPORT_SYMBOL_NS(sym, sec, ns) \
+#define __EXPORT_SYMBOL(sym, sec, ns) \
__ksym_marker(sym); \
- __cond_export_ns_sym(sym, sec, ns, __is_defined(__KSYM_##sym))
-#define __cond_export_ns_sym(sym, sec, ns, conf) \
- ___cond_export_ns_sym(sym, sec, ns, conf)
-#define ___cond_export_ns_sym(sym, sec, ns, enabled) \
- __cond_export_ns_sym_##enabled(sym, sec, ns)
-#define __cond_export_ns_sym_1(sym, sec, ns) ___EXPORT_SYMBOL_NS(sym, sec, ns)
-#define __cond_export_ns_sym_0(sym, sec, ns) /* nothing */
+ __cond_export_sym(sym, sec, ns, __is_defined(__KSYM_##sym))
+#define __cond_export_sym(sym, sec, ns, conf) \
+ ___cond_export_sym(sym, sec, ns, conf)
+#define ___cond_export_sym(sym, sec, ns, enabled) \
+ __cond_export_sym_##enabled(sym, sec, ns)
+#define __cond_export_sym_1(sym, sec, ns) ___EXPORT_SYMBOL(sym, sec, ns)
+#define __cond_export_sym_0(sym, sec, ns) /* nothing */

#else

-#define __EXPORT_SYMBOL_NS(sym,sec,ns) ___EXPORT_SYMBOL_NS(sym,sec,ns)
-#define __EXPORT_SYMBOL(sym,sec) ___EXPORT_SYMBOL(sym,sec)
+#define __EXPORT_SYMBOL(sym, sec, ns) ___EXPORT_SYMBOL(sym, sec, ns)

#endif /* CONFIG_MODULES */

#ifdef DEFAULT_SYMBOL_NAMESPACE
-#undef __EXPORT_SYMBOL
-#define __EXPORT_SYMBOL(sym, sec) \
- __EXPORT_SYMBOL_NS(sym, sec, DEFAULT_SYMBOL_NAMESPACE)
+#include <linux/stringify.h>
+#define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, __stringify(DEFAULT_SYMBOL_NAMESPACE))
+#else
+#define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, "")
#endif

-#define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "")
-#define EXPORT_SYMBOL_GPL(sym) __EXPORT_SYMBOL(sym, "_gpl")
-#define EXPORT_SYMBOL_GPL_FUTURE(sym) __EXPORT_SYMBOL(sym, "_gpl_future")
-#define EXPORT_SYMBOL_NS(sym, ns) __EXPORT_SYMBOL_NS(sym, "", ns)
-#define EXPORT_SYMBOL_NS_GPL(sym, ns) __EXPORT_SYMBOL_NS(sym, "_gpl", ns)
+#define EXPORT_SYMBOL(sym) _EXPORT_SYMBOL(sym, "")
+#define EXPORT_SYMBOL_GPL(sym) _EXPORT_SYMBOL(sym, "_gpl")
+#define EXPORT_SYMBOL_GPL_FUTURE(sym) _EXPORT_SYMBOL(sym, "_gpl_future")
+#define EXPORT_SYMBOL_NS(sym, ns) __EXPORT_SYMBOL(sym, "", #ns)
+#define EXPORT_SYMBOL_NS_GPL(sym, ns) __EXPORT_SYMBOL(sym, "_gpl", #ns)

#ifdef CONFIG_UNUSED_SYMBOLS
-#define EXPORT_UNUSED_SYMBOL(sym) __EXPORT_SYMBOL(sym, "_unused")
-#define EXPORT_UNUSED_SYMBOL_GPL(sym) __EXPORT_SYMBOL(sym, "_unused_gpl")
+#define EXPORT_UNUSED_SYMBOL(sym) _EXPORT_SYMBOL(sym, "_unused")
+#define EXPORT_UNUSED_SYMBOL_GPL(sym) _EXPORT_SYMBOL(sym, "_unused_gpl")
#else
#define EXPORT_UNUSED_SYMBOL(sym)
#define EXPORT_UNUSED_SYMBOL_GPL(sym)
diff --git a/kernel/module.c b/kernel/module.c
index ff2d7359a418..26c13173da3d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1400,7 +1400,7 @@ static int verify_namespace_is_imported(const struct load_info *info,
char *imported_namespace;

namespace = kernel_symbol_namespace(sym);
- if (namespace) {
+ if (namespace && namespace[0]) {
imported_namespace = get_modinfo(info, "import_ns");
while (imported_namespace) {
if (strcmp(namespace, imported_namespace) == 0)
--
2.23.0.581.g78d2f28ef7-goog

2019-10-11 14:25:27

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH 1/4] modpost: delegate updating namespaces to separate function

On Thu, Oct 10, 2019 at 04:14:40PM +0100, Matthias Maennich wrote:
> Let the function 'sym_update_namespace' take care of updating the
> namespace for a symbol. While this currently only replaces one single
> location where namespaces are updated, in a following patch, this
> function will get more call sites.
>
> The function signature is intentionally close to sym_update_crc and
> taking the name by char* seems like unnecessary work as the symbol has
> to be looked up again. In a later patch of this series, this concern
> will be addressed.
>
> This function ensures that symbol::namespace is either NULL or has a
> valid non-empty value. Previously, the empty string was considered 'no
> namespace' as well and this lead to confusion.
>
> Signed-off-by: Matthias Maennich <[email protected]>
> ---
> scripts/mod/modpost.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 4d2cdb4d71e3..9f5dcdff4d2f 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -362,6 +362,22 @@ static char *sym_extract_namespace(const char **symname)
> return namespace;
> }
>
> +static void sym_update_namespace(const char *symname, const char *namespace)
> +{
> + struct symbol *s = find_symbol(symname);
> + /* That symbol should have been created earlier and thus this is
> + * actually an assertion. */
> + if (!s) {
> + merror("Could not update namespace(%s) for symbol %s\n",
> + namespace, symname);
> + return;
> + }
> +
> + free(s->namespace);
> + s->namespace =
> + namespace && namespace[0] ? NOFAIL(strdup(namespace)) : NULL;
> +}

You made me look up C operator precedence again, but it's fine so:

Acked-by: Will Deacon <[email protected]>

Will

2019-10-11 14:25:33

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH 2/4] modpost: make updating the symbol namespace explict

On Thu, Oct 10, 2019 at 04:14:41PM +0100, Matthias Maennich wrote:
> Setting the symbol namespace of a symbol within sym_add_exported feels
> displaced and lead to issues in the current implementation of symbol
> namespaces. This patch makes updating the namespace an explicit call to
> decouple it from adding a symbol to the export list.
>
> Signed-off-by: Matthias Maennich <[email protected]>
> ---
> scripts/mod/modpost.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 9f5dcdff4d2f..46137b730447 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -382,8 +382,8 @@ static void sym_update_namespace(const char *symname, const char *namespace)
> * Add an exported symbol - it may have already been added without a
> * CRC, in this case just update the CRC
> **/
> -static struct symbol *sym_add_exported(const char *name, const char *namespace,
> - struct module *mod, enum export export)
> +static struct symbol *sym_add_exported(const char *name, struct module *mod,
> + enum export export)
> {
> struct symbol *s = find_symbol(name);
>
> @@ -399,7 +399,6 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,
> s->module = mod;
> }
> }
> - sym_update_namespace(name, namespace);
> s->preloaded = 0;
> s->vmlinux = is_vmlinux(mod->name);
> s->kernel = 0;
> @@ -761,7 +760,8 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
> if (strstarts(symname, "__ksymtab_")) {
> name = symname + strlen("__ksymtab_");
> namespace = sym_extract_namespace(&name);
> - sym_add_exported(name, namespace, mod, export);
> + sym_add_exported(name, mod, export);
> + sym_update_namespace(name, namespace);
> free(namespace);
> }
> if (strcmp(symname, "init_module") == 0)
> @@ -2469,12 +2469,12 @@ static void read_dump(const char *fname, unsigned int kernel)
> mod = new_module(modname);
> mod->skip = 1;
> }
> - s = sym_add_exported(symname, namespace, mod,
> - export_no(export));
> + s = sym_add_exported(symname, mod, export_no(export));
> s->kernel = kernel;
> s->preloaded = 1;
> s->is_static = 0;
> sym_update_crc(symname, mod, crc, export_no(export));
> + sym_update_namespace(symname, namespace);

This changes the order wrt setting the namespace and sym_update_crc(), but
that doesn't seem to matter, so:

Acked-by: Will Deacon <[email protected]>

Will

2019-10-11 14:28:34

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH 3/4] symbol namespaces: revert to previous __ksymtab name scheme

On Thu, Oct 10, 2019 at 04:14:42PM +0100, Matthias Maennich wrote:
> The introduction Symbol Namespaces changed the naming schema of the

Missing "of" ?

> __ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol.
>
> That caused some breakages in tools that depend on the name layout in
> either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod
> would not be able to read System.map without a patch to support symbol
> namespaces. A warning reported by depmod for namespaced symbols would
> look like
>
> depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks
>
> In order to address this issue, revert to the original naming scheme and
> rather read the __kstrtabns_<symbol> entries and their corresponding
> values from __ksymtab_strings to update the namespace values for
> symbols. After having read all symbols and handled them in
> handle_modversions(), the symbols are created. In a second pass, read
> the __kstrtabns_ entries and update the namespaces accordingly.
>
> Suggested-by: Jessica Yu <[email protected]>
> Fixes: 8651ec01daed ("module: add support for symbol namespaces.")
> Signed-off-by: Matthias Maennich <[email protected]>
> ---
> include/linux/export.h | 13 +++++--------
> scripts/mod/modpost.c | 33 ++++++++++++++++++---------------
> scripts/mod/modpost.h | 1 +
> 3 files changed, 24 insertions(+), 23 deletions(-)

Patch looks fine, and it would be good to have this fixed in 5.4:

Acked-by: Will Deacon <[email protected]>

Will

2019-10-11 15:33:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4/4] export: avoid code duplication in include/linux/export.h

On Thu, Oct 10, 2019 at 04:14:43PM +0100, Matthias Maennich wrote:
> Now that the namespace value is not part of the __ksymtab entry name
> anymore, we can simplify the implementation of EXPORT_SYMBOL*. By
> allowing the empty string "" to represent 'no namespace', we can unify
> the implementation and drop a lot redundant code. That increases
> readability and maintainability.
>
> As Masahiro pointed out earlier,
> "The drawback of this change is, it grows the code size. When the symbol
> has no namespace, sym->namespace was previously NULL, but it is now am
> empty string "". So, it increases 1 byte for every no namespace
> EXPORT_SYMBOL. A typical kernel configuration has 10K exported symbols,
> so it increases 10KB in rough estimation."

10Kb of non-swapable memory isn't good. But if you care about that, you
can get it back with the option to compile away any non-used symbols,
and that shouldn't be affected by this change, right?

That being said, the code is a lot cleaner, so I have no objection to
it.

Reviewed-by: Greg Kroah-Hartman <[email protected]>

2019-10-11 15:34:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 2/4] modpost: make updating the symbol namespace explict

On Thu, Oct 10, 2019 at 04:14:41PM +0100, Matthias Maennich wrote:
> Setting the symbol namespace of a symbol within sym_add_exported feels
> displaced and lead to issues in the current implementation of symbol
> namespaces. This patch makes updating the namespace an explicit call to
> decouple it from adding a symbol to the export list.
>
> Signed-off-by: Matthias Maennich <[email protected]>

Reviewed-by: Greg Kroah-Hartman <[email protected]>

2019-10-11 15:36:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 1/4] modpost: delegate updating namespaces to separate function

On Thu, Oct 10, 2019 at 04:14:40PM +0100, Matthias Maennich wrote:
> Let the function 'sym_update_namespace' take care of updating the
> namespace for a symbol. While this currently only replaces one single
> location where namespaces are updated, in a following patch, this
> function will get more call sites.
>
> The function signature is intentionally close to sym_update_crc and
> taking the name by char* seems like unnecessary work as the symbol has
> to be looked up again. In a later patch of this series, this concern
> will be addressed.
>
> This function ensures that symbol::namespace is either NULL or has a
> valid non-empty value. Previously, the empty string was considered 'no
> namespace' as well and this lead to confusion.
>
> Signed-off-by: Matthias Maennich <[email protected]>
> ---
> scripts/mod/modpost.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 4d2cdb4d71e3..9f5dcdff4d2f 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -362,6 +362,22 @@ static char *sym_extract_namespace(const char **symname)
> return namespace;
> }
>
> +static void sym_update_namespace(const char *symname, const char *namespace)
> +{
> + struct symbol *s = find_symbol(symname);
> + /* That symbol should have been created earlier and thus this is
> + * actually an assertion. */

Do we care about checkpatch issues in tools?

If so, you need a blank line before the comment :)

Anyway, not a big deal

Reviewed-by: Greg Kroah-Hartman <[email protected]>

2019-10-11 15:37:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3/4] symbol namespaces: revert to previous __ksymtab name scheme

On Thu, Oct 10, 2019 at 04:14:42PM +0100, Matthias Maennich wrote:
> The introduction Symbol Namespaces changed the naming schema of the
> __ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol.
>
> That caused some breakages in tools that depend on the name layout in
> either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod
> would not be able to read System.map without a patch to support symbol
> namespaces. A warning reported by depmod for namespaced symbols would
> look like
>
> depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks
>
> In order to address this issue, revert to the original naming scheme and
> rather read the __kstrtabns_<symbol> entries and their corresponding
> values from __ksymtab_strings to update the namespace values for
> symbols. After having read all symbols and handled them in
> handle_modversions(), the symbols are created. In a second pass, read
> the __kstrtabns_ entries and update the namespaces accordingly.
>
> Suggested-by: Jessica Yu <[email protected]>
> Fixes: 8651ec01daed ("module: add support for symbol namespaces.")
> Signed-off-by: Matthias Maennich <[email protected]>

Reviewed-by: Greg Kroah-Hartman <[email protected]>

2019-10-11 15:44:10

by Matthias Maennich

[permalink] [raw]
Subject: Re: [PATCH 4/4] export: avoid code duplication in include/linux/export.h

On Fri, Oct 11, 2019 at 05:31:27PM +0200, Greg Kroah-Hartman wrote:
>On Thu, Oct 10, 2019 at 04:14:43PM +0100, Matthias Maennich wrote:
>> Now that the namespace value is not part of the __ksymtab entry name
>> anymore, we can simplify the implementation of EXPORT_SYMBOL*. By
>> allowing the empty string "" to represent 'no namespace', we can unify
>> the implementation and drop a lot redundant code. That increases
>> readability and maintainability.
>>
>> As Masahiro pointed out earlier,
>> "The drawback of this change is, it grows the code size. When the symbol
>> has no namespace, sym->namespace was previously NULL, but it is now am
>> empty string "". So, it increases 1 byte for every no namespace
>> EXPORT_SYMBOL. A typical kernel configuration has 10K exported symbols,
>> so it increases 10KB in rough estimation."
>
>10Kb of non-swapable memory isn't good. But if you care about that, you
>can get it back with the option to compile away any non-used symbols,
>and that shouldn't be affected by this change, right?

Rasmus suggested to put the 'aMS' flags on the __ksymtab_strings section
to mitigate this:
https://lore.kernel.org/lkml/[email protected]/

I was not yet able to properly test this, so I did not include it in
this series. As I said in the cover letter, this 4th patch might be
optional for 5.4. So, we could defer it to a later time when we have
addressed that properly.

Cheers,
Matthias

>
>That being said, the code is a lot cleaner, so I have no objection to
>it.
>
>Reviewed-by: Greg Kroah-Hartman <[email protected]>

2019-10-12 03:23:55

by Masahiro Yamada

[permalink] [raw]
Subject: Re: [PATCH 1/4] modpost: delegate updating namespaces to separate function

On Sat, Oct 12, 2019 at 12:33 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Thu, Oct 10, 2019 at 04:14:40PM +0100, Matthias Maennich wrote:
> > Let the function 'sym_update_namespace' take care of updating the
> > namespace for a symbol. While this currently only replaces one single
> > location where namespaces are updated, in a following patch, this
> > function will get more call sites.
> >
> > The function signature is intentionally close to sym_update_crc and
> > taking the name by char* seems like unnecessary work as the symbol has
> > to be looked up again. In a later patch of this series, this concern
> > will be addressed.
> >
> > This function ensures that symbol::namespace is either NULL or has a
> > valid non-empty value. Previously, the empty string was considered 'no
> > namespace' as well and this lead to confusion.
> >
> > Signed-off-by: Matthias Maennich <[email protected]>
> > ---
> > scripts/mod/modpost.c | 21 ++++++++++++++++++---
> > 1 file changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > index 4d2cdb4d71e3..9f5dcdff4d2f 100644
> > --- a/scripts/mod/modpost.c
> > +++ b/scripts/mod/modpost.c
> > @@ -362,6 +362,22 @@ static char *sym_extract_namespace(const char **symname)
> > return namespace;
> > }
> >
> > +static void sym_update_namespace(const char *symname, const char *namespace)
> > +{
> > + struct symbol *s = find_symbol(symname);
> > + /* That symbol should have been created earlier and thus this is
> > + * actually an assertion. */
>
> Do we care about checkpatch issues in tools?

Personally, I do.


>
> If so, you need a blank line before the comment :)

One more minor issue, the block comment style is not correct.
Please do like this:

/*
* Blah Blah ...
* Blah Blha ...
*/

With those addressed,

Reviewed-by: Masahiro Yamada <[email protected]>



>
> Anyway, not a big deal
>
> Reviewed-by: Greg Kroah-Hartman <[email protected]>





--
Best Regards
Masahiro Yamada

2019-10-12 03:24:25

by Masahiro Yamada

[permalink] [raw]
Subject: Re: [PATCH 2/4] modpost: make updating the symbol namespace explict

On Fri, Oct 11, 2019 at 12:16 AM Matthias Maennich <[email protected]> wrote:
>
> Setting the symbol namespace of a symbol within sym_add_exported feels
> displaced and lead to issues in the current implementation of symbol
> namespaces. This patch makes updating the namespace an explicit call to
> decouple it from adding a symbol to the export list.
>
> Signed-off-by: Matthias Maennich <[email protected]>
> ---


Reviewed-by: Masahiro Yamada <[email protected]>



> scripts/mod/modpost.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 9f5dcdff4d2f..46137b730447 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -382,8 +382,8 @@ static void sym_update_namespace(const char *symname, const char *namespace)
> * Add an exported symbol - it may have already been added without a
> * CRC, in this case just update the CRC
> **/
> -static struct symbol *sym_add_exported(const char *name, const char *namespace,
> - struct module *mod, enum export export)
> +static struct symbol *sym_add_exported(const char *name, struct module *mod,
> + enum export export)
> {
> struct symbol *s = find_symbol(name);
>
> @@ -399,7 +399,6 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,
> s->module = mod;
> }
> }
> - sym_update_namespace(name, namespace);
> s->preloaded = 0;
> s->vmlinux = is_vmlinux(mod->name);
> s->kernel = 0;
> @@ -761,7 +760,8 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
> if (strstarts(symname, "__ksymtab_")) {
> name = symname + strlen("__ksymtab_");
> namespace = sym_extract_namespace(&name);
> - sym_add_exported(name, namespace, mod, export);
> + sym_add_exported(name, mod, export);
> + sym_update_namespace(name, namespace);
> free(namespace);
> }
> if (strcmp(symname, "init_module") == 0)
> @@ -2469,12 +2469,12 @@ static void read_dump(const char *fname, unsigned int kernel)
> mod = new_module(modname);
> mod->skip = 1;
> }
> - s = sym_add_exported(symname, namespace, mod,
> - export_no(export));
> + s = sym_add_exported(symname, mod, export_no(export));
> s->kernel = kernel;
> s->preloaded = 1;
> s->is_static = 0;
> sym_update_crc(symname, mod, crc, export_no(export));
> + sym_update_namespace(symname, namespace);
> }
> release_file(file, size);
> return;
> --
> 2.23.0.581.g78d2f28ef7-goog
>


--
Best Regards
Masahiro Yamada

2019-10-12 03:41:30

by Masahiro Yamada

[permalink] [raw]
Subject: Re: [PATCH 3/4] symbol namespaces: revert to previous __ksymtab name scheme

On Fri, Oct 11, 2019 at 12:16 AM Matthias Maennich <[email protected]> wrote:
>
> The introduction Symbol Namespaces changed the naming schema of the
> __ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol.
>
> That caused some breakages in tools that depend on the name layout in
> either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod
> would not be able to read System.map without a patch to support symbol
> namespaces. A warning reported by depmod for namespaced symbols would
> look like
>
> depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks
>
> In order to address this issue, revert to the original naming scheme and
> rather read the __kstrtabns_<symbol> entries and their corresponding
> values from __ksymtab_strings to update the namespace values for
> symbols. After having read all symbols and handled them in
> handle_modversions(), the symbols are created. In a second pass, read
> the __kstrtabns_ entries and update the namespaces accordingly.
>
> Suggested-by: Jessica Yu <[email protected]>
> Fixes: 8651ec01daed ("module: add support for symbol namespaces.")
> Signed-off-by: Matthias Maennich <[email protected]>


According to https://lore.kernel.org/patchwork/patch/1135222/
was this problem reported by Stefan?
Reported-by: Stefan Wahren <[email protected]>


BTW, I initially suggested this way of fixing.
Suggested-by: Masahiro Yamada <[email protected]>



> @@ -74,9 +72,8 @@ struct kernel_symbol {
> int namespace_offset;
> };
> #else
> -#define __KSYMTAB_ENTRY_NS(sym, sec, ns) \
> - static const struct kernel_symbol __ksymtab_##sym##__##ns \
> - asm("__ksymtab_" #ns NS_SEPARATOR #sym) \


For consistency, you could also delete asm("__ksymtab_" #sym)
by this patch instead of by 4/4.

Not a big deal, though.


Reviewed-by: Masahiro Yamada <[email protected]>



--
Best Regards
Masahiro Yamada

2019-10-12 04:29:23

by Masahiro Yamada

[permalink] [raw]
Subject: Re: [PATCH 4/4] export: avoid code duplication in include/linux/export.h

On Sat, Oct 12, 2019 at 12:43 AM Matthias Maennich <[email protected]> wrote:
>
> On Fri, Oct 11, 2019 at 05:31:27PM +0200, Greg Kroah-Hartman wrote:
> >On Thu, Oct 10, 2019 at 04:14:43PM +0100, Matthias Maennich wrote:
> >> Now that the namespace value is not part of the __ksymtab entry name
> >> anymore, we can simplify the implementation of EXPORT_SYMBOL*. By
> >> allowing the empty string "" to represent 'no namespace', we can unify
> >> the implementation and drop a lot redundant code. That increases
> >> readability and maintainability.
> >>
> >> As Masahiro pointed out earlier,
> >> "The drawback of this change is, it grows the code size. When the symbol
> >> has no namespace, sym->namespace was previously NULL, but it is now am
> >> empty string "". So, it increases 1 byte for every no namespace
> >> EXPORT_SYMBOL. A typical kernel configuration has 10K exported symbols,
> >> so it increases 10KB in rough estimation."
> >
> >10Kb of non-swapable memory isn't good. But if you care about that, you
> >can get it back with the option to compile away any non-used symbols,
> >and that shouldn't be affected by this change, right?
>
> Rasmus suggested to put the 'aMS' flags on the __ksymtab_strings section
> to mitigate this:
> https://lore.kernel.org/lkml/[email protected]/
>
> I was not yet able to properly test this, so I did not include it in
> this series. As I said in the cover letter, this 4th patch might be
> optional for 5.4. So, we could defer it to a later time when we have
> addressed that properly.


This looks the same as my patch, though.

Reviewed-by: Masahiro Yamada <[email protected]>


--
Best Regards
Masahiro Yamada

2019-10-19 08:07:38

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH v2 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces

The introduction of the symbol namespace patches changed the way symbols are
named in the ksymtab entries. That caused userland tools to fail (such as
kmod's depmod). As depmod is used as part of the kernel build it was worth
having another look whether this name change can be avoided.

The main purpose of this series is to restore the original ksymtab entry names.
For that to happen and to remove some rough edges around that, the relevant
parts in modpost got a small refactoring as to when and how namespaces are
evaluated and set in the symbol struct.

Eventually, the namespace values can be read from __kstrtabns_ entries and
their corresponding __ksymtab_strings values. That removes the need to carry
the namespace names within the (anyway unique) symbol name entries.

The last patch of this series is adopted from Masahiro [1]. By allowing 'no
namespace' to be represented as empty string, large chunks of
include/linux/export.h could be consolidated. Technically, this last patch is
not absolutely necessary to fix functionality. It addresses concerns about
maintainability and readability. While I strongly suggest sending all of the
patches for 5.4, the last one could possible deferred to the next merge window.

This patch applies to the modules-linus [2] branch.

Changes since v2:
- restored correct authorship for [4/4]
- add missing contributor tags
- fixed typos and code style (spaces/tabs)

[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git/log/?h=modules-linus

Cc: Jessica Yu <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Martijn Coenen <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Shaun Ruffell <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Cc: [email protected]


Masahiro Yamada (1):
export: avoid code duplication in include/linux/export.h

Matthias Maennich (3):
modpost: delegate updating namespaces to separate function
modpost: make updating the symbol namespace explicit
symbol namespaces: revert to previous __ksymtab name scheme

include/linux/export.h | 97 +++++++++++++-----------------------------
kernel/module.c | 2 +-
scripts/mod/modpost.c | 59 ++++++++++++++++---------
scripts/mod/modpost.h | 1 +
4 files changed, 71 insertions(+), 88 deletions(-)

Interdiff against v1:
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 7cf0065ac95f..0bf7eab80d9f 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -357,18 +357,21 @@ static const char *namespace_from_kstrtabns(struct elf_info *info,

static void sym_update_namespace(const char *symname, const char *namespace)
{
- struct symbol *s = find_symbol(symname);
- /* That symbol should have been created earlier and thus this is
- * actually an assertion. */
- if (!s) {
- merror("Could not update namespace(%s) for symbol %s\n",
- namespace, symname);
- return;
- }
-
- free(s->namespace);
- s->namespace =
- namespace && namespace[0] ? NOFAIL(strdup(namespace)) : NULL;
+ struct symbol *s = find_symbol(symname);
+
+ /*
+ * That symbol should have been created earlier and thus this is
+ * actually an assertion.
+ */
+ if (!s) {
+ merror("Could not update namespace(%s) for symbol %s\n",
+ namespace, symname);
+ return;
+ }
+
+ free(s->namespace);
+ s->namespace =
+ namespace && namespace[0] ? NOFAIL(strdup(namespace)) : NULL;
}

/**
--
2.23.0.866.gb869b98d4c-goog

2019-10-19 08:07:42

by Matthias Maennich

[permalink] [raw]
Subject: [PATCH v2 2/4] modpost: make updating the symbol namespace explicit

Setting the symbol namespace of a symbol within sym_add_exported feels
displaced and lead to issues in the current implementation of symbol
namespaces. This patch makes updating the namespace an explicit call to
decouple it from adding a symbol to the export list.

Acked-by: Will Deacon <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Masahiro Yamada <[email protected]>
Signed-off-by: Matthias Maennich <[email protected]>
---
scripts/mod/modpost.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index dbfa3997136b..95b1eac656aa 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -385,8 +385,8 @@ static void sym_update_namespace(const char *symname, const char *namespace)
* Add an exported symbol - it may have already been added without a
* CRC, in this case just update the CRC
**/
-static struct symbol *sym_add_exported(const char *name, const char *namespace,
- struct module *mod, enum export export)
+static struct symbol *sym_add_exported(const char *name, struct module *mod,
+ enum export export)
{
struct symbol *s = find_symbol(name);

@@ -402,7 +402,6 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,
s->module = mod;
}
}
- sym_update_namespace(name, namespace);
s->preloaded = 0;
s->vmlinux = is_vmlinux(mod->name);
s->kernel = 0;
@@ -764,7 +763,8 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
if (strstarts(symname, "__ksymtab_")) {
name = symname + strlen("__ksymtab_");
namespace = sym_extract_namespace(&name);
- sym_add_exported(name, namespace, mod, export);
+ sym_add_exported(name, mod, export);
+ sym_update_namespace(name, namespace);
free(namespace);
}
if (strcmp(symname, "init_module") == 0)
@@ -2472,12 +2472,12 @@ static void read_dump(const char *fname, unsigned int kernel)
mod = new_module(modname);
mod->skip = 1;
}
- s = sym_add_exported(symname, namespace, mod,
- export_no(export));
+ s = sym_add_exported(symname, mod, export_no(export));
s->kernel = kernel;
s->preloaded = 1;
s->is_static = 0;
sym_update_crc(symname, mod, crc, export_no(export));
+ sym_update_namespace(symname, namespace);
}
release_file(file, size);
return;
--
2.23.0.866.gb869b98d4c-goog

2019-10-21 13:35:16

by Jessica Yu

[permalink] [raw]
Subject: Re: [PATCH v2 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces

+++ Matthias Maennich [18/10/19 10:31 +0100]:
>The introduction of the symbol namespace patches changed the way symbols are
>named in the ksymtab entries. That caused userland tools to fail (such as
>kmod's depmod). As depmod is used as part of the kernel build it was worth
>having another look whether this name change can be avoided.
>
>The main purpose of this series is to restore the original ksymtab entry names.
>For that to happen and to remove some rough edges around that, the relevant
>parts in modpost got a small refactoring as to when and how namespaces are
>evaluated and set in the symbol struct.
>
>Eventually, the namespace values can be read from __kstrtabns_ entries and
>their corresponding __ksymtab_strings values. That removes the need to carry
>the namespace names within the (anyway unique) symbol name entries.
>
>The last patch of this series is adopted from Masahiro [1]. By allowing 'no
>namespace' to be represented as empty string, large chunks of
>include/linux/export.h could be consolidated. Technically, this last patch is
>not absolutely necessary to fix functionality. It addresses concerns about
>maintainability and readability. While I strongly suggest sending all of the
>patches for 5.4, the last one could possible deferred to the next merge window.
>
>This patch applies to the modules-linus [2] branch.

Hi!

I've applied the first three patches to modules-linus, inbound for -rc5.

Patch 4/4 was agreed to be for 5.5, and will be applied to
modules-next once I rebase that branch against -rc5.

Thanks!

Jessica

>Changes since v2:
> - restored correct authorship for [4/4]
> - add missing contributor tags
> - fixed typos and code style (spaces/tabs)
>
>[1] https://lore.kernel.org/lkml/[email protected]/
>[2] https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git/log/?h=modules-linus
>
>Cc: Jessica Yu <[email protected]>
>Cc: Masahiro Yamada <[email protected]>
>Cc: Martijn Coenen <[email protected]>
>Cc: Lucas De Marchi <[email protected]>
>Cc: Shaun Ruffell <[email protected]>
>Cc: Greg Kroah-Hartman <[email protected]>
>Cc: Will Deacon <[email protected]>
>Cc: [email protected]
>Cc: [email protected]
>
>
>Masahiro Yamada (1):
> export: avoid code duplication in include/linux/export.h
>
>Matthias Maennich (3):
> modpost: delegate updating namespaces to separate function
> modpost: make updating the symbol namespace explicit
> symbol namespaces: revert to previous __ksymtab name scheme
>
> include/linux/export.h | 97 +++++++++++++-----------------------------
> kernel/module.c | 2 +-
> scripts/mod/modpost.c | 59 ++++++++++++++++---------
> scripts/mod/modpost.h | 1 +
> 4 files changed, 71 insertions(+), 88 deletions(-)
>
>Interdiff against v1:
>diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
>index 7cf0065ac95f..0bf7eab80d9f 100644
>--- a/scripts/mod/modpost.c
>+++ b/scripts/mod/modpost.c
>@@ -357,18 +357,21 @@ static const char *namespace_from_kstrtabns(struct elf_info *info,
>
> static void sym_update_namespace(const char *symname, const char *namespace)
> {
>- struct symbol *s = find_symbol(symname);
>- /* That symbol should have been created earlier and thus this is
>- * actually an assertion. */
>- if (!s) {
>- merror("Could not update namespace(%s) for symbol %s\n",
>- namespace, symname);
>- return;
>- }
>-
>- free(s->namespace);
>- s->namespace =
>- namespace && namespace[0] ? NOFAIL(strdup(namespace)) : NULL;
>+ struct symbol *s = find_symbol(symname);
>+
>+ /*
>+ * That symbol should have been created earlier and thus this is
>+ * actually an assertion.
>+ */
>+ if (!s) {
>+ merror("Could not update namespace(%s) for symbol %s\n",
>+ namespace, symname);
>+ return;
>+ }
>+
>+ free(s->namespace);
>+ s->namespace =
>+ namespace && namespace[0] ? NOFAIL(strdup(namespace)) : NULL;
> }
>
> /**
>--
>2.23.0.866.gb869b98d4c-goog
>

2019-10-23 13:18:22

by Luis Chamberlain

[permalink] [raw]
Subject: Re: [PATCH v2 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces

On Fri, Oct 18, 2019 at 10:31:39AM +0100, Matthias Maennich wrote:
> The introduction of the symbol namespace patches changed the way symbols are
> named in the ksymtab entries. That caused userland tools to fail (such as
> kmod's depmod). As depmod is used as part of the kernel build it was worth
> having another look whether this name change can be avoided.

Why have this as a default feature? What about having an option to
disable this feature? The benefit being that without a full swing of
tests to avoid regressions its not clear what other issues may creep
up. With this as optional, those wanting the mechanism can enable it
and happilly find the issues for those more conservative.

Luis

2019-10-25 05:31:56

by Matthias Maennich

[permalink] [raw]
Subject: Re: [PATCH v2 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces

On Wed, Oct 23, 2019 at 12:22:22PM +0000, Luis Chamberlain wrote:
>On Fri, Oct 18, 2019 at 10:31:39AM +0100, Matthias Maennich wrote:
>> The introduction of the symbol namespace patches changed the way symbols are
>> named in the ksymtab entries. That caused userland tools to fail (such as
>> kmod's depmod). As depmod is used as part of the kernel build it was worth
>> having another look whether this name change can be avoided.
>
>Why have this as a default feature? What about having an option to
>disable this feature? The benefit being that without a full swing of
>tests to avoid regressions its not clear what other issues may creep
>up. With this as optional, those wanting the mechanism can enable it
>and happilly find the issues for those more conservative.

The strongest argument against that is, that the 'conservative' people
would constantly break things for the more 'adventurous' ones. They
would introduce namespace requirements by just using symbols without
correctly adjusting the imports.

Second, vmlinux and modules would have to be compiled in the same
configuration. Otherwise they are incompatible and we would likely have
to maintain code in the module loader to catch issues caused by that.
In general, I think for the adoption of this feature and one of its
purposes - making unexpected use of symbols across the tree visible
already at review time - we should not make this an optional one.
Enforcing the imports at module load time is optional (there is an
option).

And finally, having that code configurable for both options introduces
quite some complexity in kernel/module.c, modpost and
include/linux/export.h that would make the code hard to maintain and
complex to test. Hence that would likely introduce more issues.

I know the feature came with some rough edges. Sorry about that. I
think, we got most of them worked out pretty well (big thanks to
Masahiro and Jessica and others helping with that). Now the actual
change to the surface exposed to userland tools is much smaller and the
feature itself less intrusive.

Cheers,
Matthias

>
> Luis

2019-10-25 08:25:30

by Luis Chamberlain

[permalink] [raw]
Subject: Re: [PATCH v2 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces

On Thu, Oct 24, 2019 at 10:35:46AM +0100, Matthias Maennich wrote:
> On Wed, Oct 23, 2019 at 12:22:22PM +0000, Luis Chamberlain wrote:
> > On Fri, Oct 18, 2019 at 10:31:39AM +0100, Matthias Maennich wrote:
> > > The introduction of the symbol namespace patches changed the way symbols are
> > > named in the ksymtab entries. That caused userland tools to fail (such as
> > > kmod's depmod). As depmod is used as part of the kernel build it was worth
> > > having another look whether this name change can be avoided.
> >
> > Why have this as a default feature? What about having an option to
> > disable this feature? The benefit being that without a full swing of
> > tests to avoid regressions its not clear what other issues may creep
> > up. With this as optional, those wanting the mechanism can enable it
> > and happilly find the issues for those more conservative.
>
> The strongest argument against that is, that the 'conservative' people
> would constantly break things for the more 'adventurous' ones. They
> would introduce namespace requirements by just using symbols without
> correctly adjusting the imports.
>
> Second, vmlinux and modules would have to be compiled in the same
> configuration. Otherwise they are incompatible and we would likely have
> to maintain code in the module loader to catch issues caused by that.
> In general, I think for the adoption of this feature and one of its
> purposes - making unexpected use of symbols across the tree visible
> already at review time - we should not make this an optional one.
> Enforcing the imports at module load time is optional (there is an
> option).
>
> And finally, having that code configurable for both options introduces
> quite some complexity in kernel/module.c, modpost and
> include/linux/export.h that would make the code hard to maintain and
> complex to test. Hence that would likely introduce more issues.
>
> I know the feature came with some rough edges. Sorry about that. I
> think, we got most of them worked out pretty well (big thanks to
> Masahiro and Jessica and others helping with that). Now the actual
> change to the surface exposed to userland tools is much smaller and the
> feature itself less intrusive.

This logic makes sense, the complexity over module loading is already
high and supporting yet another division would be a burden for review
and maintenace.

However I'd feel much more inclined to support such decisions when and if
we had a series of test cases to prevent possible regressions. Since
effort with testing will move forward, I'm happy with the status quo.

Luis