2022-03-22 17:03:43 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
/*
|
|
|
|
* Module kdb support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2010 Jason Wessel
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/kdb.h>
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* kdb_lsmod - This function implements the 'lsmod' command. Lists
|
|
|
|
* currently loaded kernel modules.
|
|
|
|
* Mostly taken from userland lsmod.
|
|
|
|
*/
|
|
|
|
int kdb_lsmod(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct module *mod;
|
|
|
|
|
|
|
|
if (argc != 0)
|
|
|
|
return KDB_ARGCOUNT;
|
|
|
|
|
|
|
|
kdb_printf("Module Size modstruct Used by\n");
|
|
|
|
list_for_each_entry(mod, &modules, list) {
|
|
|
|
if (mod->state == MODULE_STATE_UNFORMED)
|
|
|
|
continue;
|
|
|
|
|
module: replace module_layout with module_memory
module_layout manages different types of memory (text, data, rodata, etc.)
in one allocation, which is problematic for some reasons:
1. It is hard to enable CONFIG_STRICT_MODULE_RWX.
2. It is hard to use huge pages in modules (and not break strict rwx).
3. Many archs uses module_layout for arch-specific data, but it is not
obvious how these data are used (are they RO, RX, or RW?)
Improve the scenario by replacing 2 (or 3) module_layout per module with
up to 7 module_memory per module:
MOD_TEXT,
MOD_DATA,
MOD_RODATA,
MOD_RO_AFTER_INIT,
MOD_INIT_TEXT,
MOD_INIT_DATA,
MOD_INIT_RODATA,
and allocating them separately. This adds slightly more entries to
mod_tree (from up to 3 entries per module, to up to 7 entries per
module). However, this at most adds a small constant overhead to
__module_address(), which is expected to be fast.
Various archs use module_layout for different data. These data are put
into different module_memory based on their location in module_layout.
IOW, data that used to go with text is allocated with MOD_MEM_TYPE_TEXT;
data that used to go with data is allocated with MOD_MEM_TYPE_DATA, etc.
module_memory simplifies quite some of the module code. For example,
ARCH_WANTS_MODULES_DATA_IN_VMALLOC is a lot cleaner, as it just uses a
different allocator for the data. kernel/module/strict_rwx.c is also
much cleaner with module_memory.
Signed-off-by: Song Liu <song@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-02-07 03:28:02 +03:00
|
|
|
kdb_printf("%-20s%8u", mod->name, mod->mem[MOD_TEXT].size);
|
|
|
|
kdb_printf("/%8u", mod->mem[MOD_RODATA].size);
|
|
|
|
kdb_printf("/%8u", mod->mem[MOD_RO_AFTER_INIT].size);
|
|
|
|
kdb_printf("/%8u", mod->mem[MOD_DATA].size);
|
|
|
|
|
2022-02-23 15:02:14 +03:00
|
|
|
kdb_printf(" 0x%px ", (void *)mod);
|
2022-03-22 17:03:43 +03:00
|
|
|
#ifdef CONFIG_MODULE_UNLOAD
|
|
|
|
kdb_printf("%4d ", module_refcount(mod));
|
|
|
|
#endif
|
|
|
|
if (mod->state == MODULE_STATE_GOING)
|
|
|
|
kdb_printf(" (Unloading)");
|
|
|
|
else if (mod->state == MODULE_STATE_COMING)
|
|
|
|
kdb_printf(" (Loading)");
|
|
|
|
else
|
|
|
|
kdb_printf(" (Live)");
|
module: replace module_layout with module_memory
module_layout manages different types of memory (text, data, rodata, etc.)
in one allocation, which is problematic for some reasons:
1. It is hard to enable CONFIG_STRICT_MODULE_RWX.
2. It is hard to use huge pages in modules (and not break strict rwx).
3. Many archs uses module_layout for arch-specific data, but it is not
obvious how these data are used (are they RO, RX, or RW?)
Improve the scenario by replacing 2 (or 3) module_layout per module with
up to 7 module_memory per module:
MOD_TEXT,
MOD_DATA,
MOD_RODATA,
MOD_RO_AFTER_INIT,
MOD_INIT_TEXT,
MOD_INIT_DATA,
MOD_INIT_RODATA,
and allocating them separately. This adds slightly more entries to
mod_tree (from up to 3 entries per module, to up to 7 entries per
module). However, this at most adds a small constant overhead to
__module_address(), which is expected to be fast.
Various archs use module_layout for different data. These data are put
into different module_memory based on their location in module_layout.
IOW, data that used to go with text is allocated with MOD_MEM_TYPE_TEXT;
data that used to go with data is allocated with MOD_MEM_TYPE_DATA, etc.
module_memory simplifies quite some of the module code. For example,
ARCH_WANTS_MODULES_DATA_IN_VMALLOC is a lot cleaner, as it just uses a
different allocator for the data. kernel/module/strict_rwx.c is also
much cleaner with module_memory.
Signed-off-by: Song Liu <song@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-02-07 03:28:02 +03:00
|
|
|
kdb_printf(" 0x%px", mod->mem[MOD_TEXT].base);
|
|
|
|
kdb_printf("/0x%px", mod->mem[MOD_RODATA].base);
|
|
|
|
kdb_printf("/0x%px", mod->mem[MOD_RO_AFTER_INIT].base);
|
|
|
|
kdb_printf("/0x%px", mod->mem[MOD_DATA].base);
|
2022-03-22 17:03:43 +03:00
|
|
|
|
|
|
|
#ifdef CONFIG_MODULE_UNLOAD
|
|
|
|
{
|
|
|
|
struct module_use *use;
|
|
|
|
|
|
|
|
kdb_printf(" [ ");
|
|
|
|
list_for_each_entry(use, &mod->source_list,
|
|
|
|
source_list)
|
|
|
|
kdb_printf("%s ", use->target->name);
|
|
|
|
kdb_printf("]\n");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|