linux: generalize sections, ranges and linker tables
Subsystems (31)
Luis R. Rodriguez
maintainerv3 cover linux: generalize sections, ranges and linker tables
This RFC v3 builds off the last RFC v2 series [0] for adding linker tables. The largest amount of work here was to take Russell King's feedback on using linker table for kprobes text not being appropriate -- and providing another lightweight API for simple section ranges: read-only stitched pieces of executable code. This required also generalizing common building blocks for both linker tables and section ranges, these building blocks are defined now in include/linux/sections.h and asm-generic/section.h. The other last thing decided was to not support sub-sections. In the hunt for this I could think of anything that really required this, and if it was needed it did not seem impossible to port over to avoid its use. Please let me know if there are valid uses cases for sub-sections.
Other significant effort here was to provide a set of common assembly helpers which could be used across architectures, this starts off some of this work for generic helpers which carve out and define custom Linux sections.
Lastly, this now also goes with two ports which required module support when using linker tables: jump labels, and dynamic debug support. A few extensions have been made to the original series in order to provide support for that.
Since kprobes actually had both a linker table and a section range the patch that dealt with kprobes is now split off in two patches, one that deals with its linker table and another for its section ranges.
More elaborate uses for linker tables are possible, I'll hold off on any of this type of work until at least the basic building blocks are fleshed out. To review how this work came about, and more elaborate uses being evaluated check out the userspace linker-tables mockup solution [1]. Hopefully most of the possible bikeshedding was already dealt with through that tree. Thanks to hpa for tons of feedback.
Should you need it, the code here is also available on my linux-next 20160722-linker-table-v3-try2 branch on kernel.org [2]. Lastly, ranges and table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
This all goes tested by 0-day... however since I found an issue with linker tables and blackfin this series remains as RFC -- I'll try to debug the issue with Steven Miao. The issue with blackfin is using a config that enables CONFIG_FW_LOADER=y and CONFIG_DYNAMIC_DEBUG=y [5] we end up with the following at final link time:
LD init/built-in.olib/built-in.o: In function `dynamic_debug_init':
lib/dynamic_debug.c:(.init.text+0x156): undefined reference to __verbose__end' lib/dynamic_debug.c:(.init.text+0x15a): undefined reference to __verbose__end' lib/dynamic_debug.c:(.init.text+0x160): undefined reference to __verbose' lib/dynamic_debug.c:(.init.text+0x164): undefined reference to __verbose' lib/dynamic_debug.c:(.init.text+0x214): undefined reference to __verbose__end' lib/dynamic_debug.c:(.init.text+0x218): undefined reference to __verbose__end' lib/dynamic_debug.c:(.init.text+0x252): undefined reference to __verbose__end' lib/dynamic_debug.c:(.init.text+0x258): undefined reference to __verbose' lib/dynamic_debug.c:(.init.text+0x25c): undefined reference to __verbose__end' lib/dynamic_debug.c:(.init.text+0x260): undefined reference to __verbose' drivers/built-in.o: In function `release_firmware':
(.text+0x22dc2): undefined reference to `builtin_fw'drivers/built-in.o: In function `release_firmware':
(.text+0x22dc6): undefined reference to builtin_fw__end' drivers/built-in.o: In function release_firmware':
(.text+0x22dca): undefined reference to `builtin_fw'drivers/built-in.o: In function `release_firmware':
(.text+0x22dce): undefined reference to builtin_fw__end' drivers/built-in.o: In function fw_get_builtin_firmware':
drivers/base/firmware_class.c:(.text+0x23008): undefined reference to builtin_fw' drivers/base/firmware_class.c:(.text+0x2300c): undefined reference to builtin_fw__end' drivers/base/firmware_class.c:(.text+0x23010): undefined reference to builtin_fw' drivers/base/firmware_class.c:(.text+0x23014): undefined reference to builtin_fw__end' Makefile:957: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
To reproduce then:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
wget http://drvbp1.linux-foundation.org/~mcgrof/2016/07/22/blackfin-fw-dyndbg.config -o .config make.cross ARCH=blackfin
[0] https://lkml.kernel.org/r/[email protected]
[1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
[2] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160722-linker-table-v3-try2
[3] https://lkml.kernel.org/r/[email protected]
[4] https://lkml.kernel.org/r/[email protected]
[5] http://drvbp1.linux-foundation.org/~mcgrof/2016/07/22/blackfin-fw-dyndbg.config
Luis R. Rodriguez (13):
x86: remove LTO_REFERENCE_INITCALL()
dell-smo8800: include uaccess.h scripts/module-common.lds: enable generation sections.h: guard against asm and linker script sections.h: add sections header to collect all section info ranges.h: add helpers to build and identify Linux section ranges tables.h: add linker table support
firmware/Makefile: force recompilation if makefile changes
firmware: port built-in section to linker table
jump_label: port __jump_table to linker tables
dynamic_debug: port to use linker tables
kprobes: port .kprobes.text to section range
kprobes: port blacklist kprobes to linker table
.gitignore | 2 +
Documentation/DocBook/Makefile | 3 +-
Documentation/DocBook/linker-tables.tmpl | 166 ++++++
Documentation/DocBook/sections.tmpl | 112 ++++
Documentation/kbuild/makefiles.txt | 19 +
Makefile | 6 +-
arch/alpha/include/asm/ranges.h | 6 +
arch/alpha/include/asm/sections.h | 6 +
arch/alpha/include/asm/tables.h | 6 +
arch/arc/include/asm/ranges.h | 6 +
arch/arc/include/asm/tables.h | 6 +
arch/arc/kernel/vmlinux.lds.S | 1 -
arch/arm/include/asm/jump_label.h | 6 +-
arch/arm/include/asm/ranges.h | 6 +
arch/arm/include/asm/sections.h | 2 +
arch/arm/include/asm/tables.h | 6 +
arch/arm/kernel/entry-armv.S | 3 +-
arch/arm/kernel/vmlinux-xip.lds.S | 1 -
arch/arm/kernel/vmlinux.lds.S | 1 -
arch/arm64/include/asm/jump_label.h | 6 +-
arch/arm64/include/asm/ranges.h | 6 +
arch/arm64/include/asm/sections.h | 6 +
arch/arm64/include/asm/tables.h | 6 +
arch/avr32/include/asm/ranges.h | 6 +
arch/avr32/include/asm/sections.h | 6 +
arch/avr32/include/asm/tables.h | 6 +
arch/avr32/kernel/entry-avr32b.S | 5 +-
arch/avr32/kernel/vmlinux.lds.S | 1 -
arch/blackfin/include/asm/ranges.h | 6 +
arch/blackfin/include/asm/sections.h | 4 +
arch/blackfin/include/asm/tables.h | 6 +
arch/blackfin/kernel/vmlinux.lds.S | 1 -
arch/c6x/include/asm/ranges.h | 6 +
arch/c6x/include/asm/tables.h | 6 +
arch/c6x/kernel/vmlinux.lds.S | 1 -
arch/cris/include/asm/ranges.h | 6 +
arch/cris/include/asm/sections.h | 6 +
arch/cris/include/asm/tables.h | 6 +
arch/frv/include/asm/ranges.h | 6 +
arch/frv/include/asm/tables.h | 6 +
arch/h8300/include/asm/ranges.h | 6 +
arch/h8300/include/asm/sections.h | 6 +
arch/h8300/include/asm/tables.h | 6 +
arch/hexagon/include/asm/ranges.h | 6 +
arch/hexagon/include/asm/sections.h | 6 +
arch/hexagon/include/asm/tables.h | 6 +
arch/hexagon/kernel/vmlinux.lds.S | 1 -
arch/ia64/include/asm/ranges.h | 6 +
arch/ia64/include/asm/sections.h | 7 +-
arch/ia64/include/asm/tables.h | 6 +
arch/ia64/kernel/jprobes.S | 3 +-
arch/ia64/kernel/vmlinux.lds.S | 1 -
arch/ia64/lib/flush.S | 5 +-
arch/m32r/include/asm/ranges.h | 6 +
arch/m32r/include/asm/sections.h | 6 +
arch/m32r/include/asm/tables.h | 6 +
arch/m68k/include/asm/ranges.h | 6 +
arch/m68k/include/asm/sections.h | 6 +
arch/m68k/include/asm/tables.h | 6 +
arch/metag/include/asm/ranges.h | 6 +
arch/metag/include/asm/sections.h | 6 +
arch/metag/include/asm/tables.h | 6 +
arch/metag/kernel/vmlinux.lds.S | 1 -
arch/microblaze/include/asm/ranges.h | 6 +
arch/microblaze/include/asm/tables.h | 6 +
arch/microblaze/kernel/vmlinux.lds.S | 1 -
arch/mips/include/asm/jump_label.h | 6 +-
arch/mips/include/asm/ranges.h | 6 +
arch/mips/include/asm/sections.h | 6 +
arch/mips/include/asm/tables.h | 6 +
arch/mips/kernel/vmlinux.lds.S | 1 -
arch/mn10300/include/asm/ranges.h | 6 +
arch/mn10300/include/asm/sections.h | 6 +
arch/mn10300/include/asm/tables.h | 6 +
arch/mn10300/kernel/vmlinux.lds.S | 1 -
arch/nios2/include/asm/ranges.h | 6 +
arch/nios2/include/asm/sections.h | 6 +
arch/nios2/include/asm/tables.h | 6 +
arch/nios2/kernel/vmlinux.lds.S | 1 -
arch/openrisc/include/asm/ranges.h | 6 +
arch/openrisc/include/asm/sections.h | 6 +
arch/openrisc/include/asm/tables.h | 6 +
arch/openrisc/kernel/vmlinux.lds.S | 1 -
arch/parisc/include/asm/ranges.h | 6 +
arch/parisc/include/asm/tables.h | 6 +
arch/parisc/kernel/vmlinux.lds.S | 1 -
arch/powerpc/include/asm/jump_label.h | 8 +-
arch/powerpc/include/asm/ppc_asm.h | 7 +-
arch/powerpc/include/asm/ranges.h | 6 +
arch/powerpc/include/asm/sections.h | 11 +-
arch/powerpc/include/asm/tables.h | 6 +
arch/powerpc/kernel/vmlinux.lds.S | 1 -
arch/s390/include/asm/jump_label.h | 6 +-
arch/s390/include/asm/ranges.h | 6 +
arch/s390/include/asm/tables.h | 6 +
arch/s390/kernel/entry.S | 5 +-
arch/s390/kernel/kprobes.c | 6 +-
arch/s390/kernel/mcount.S | 2 +-
arch/s390/kernel/vmlinux.lds.S | 1 -
arch/score/include/asm/ranges.h | 6 +
arch/score/include/asm/sections.h | 6 +
arch/score/include/asm/tables.h | 6 +
arch/score/kernel/vmlinux.lds.S | 1 -
arch/sh/include/asm/ranges.h | 6 +
arch/sh/include/asm/sections.h | 2 +
arch/sh/include/asm/tables.h | 6 +
arch/sh/kernel/vmlinux.lds.S | 1 -
arch/sparc/include/asm/jump_label.h | 6 +-
arch/sparc/include/asm/ranges.h | 6 +
arch/sparc/include/asm/sections.h | 4 +
arch/sparc/include/asm/tables.h | 6 +
arch/sparc/kernel/vmlinux.lds.S | 1 -
arch/sparc/mm/ultra.S | 3 +-
arch/tile/include/asm/ranges.h | 6 +
arch/tile/include/asm/sections.h | 4 +
arch/tile/include/asm/tables.h | 6 +
arch/tile/kernel/vmlinux.lds.S | 1 -
arch/um/include/asm/ranges.h | 6 +
arch/um/include/asm/tables.h | 6 +
arch/unicore32/include/asm/ranges.h | 6 +
arch/unicore32/include/asm/sections.h | 6 +
arch/unicore32/include/asm/tables.h | 6 +
arch/x86/include/asm/jump_label.h | 10 +-
arch/x86/include/asm/ranges.h | 6 +
arch/x86/include/asm/sections.h | 23 +-
arch/x86/include/asm/tables.h | 6 +
arch/x86/include/asm/uaccess.h | 18 +-
arch/x86/kernel/cpu/microcode/core.c | 8 +-
arch/x86/kernel/kprobes/core.c | 11 +-
arch/x86/kernel/vmlinux.lds.S | 1 -
arch/x86/tools/relocs.c | 3 +
arch/xtensa/include/asm/ranges.h | 6 +
arch/xtensa/include/asm/sections.h | 6 +
arch/xtensa/include/asm/tables.h | 6 +
drivers/base/firmware_class.c | 12 +-
drivers/platform/x86/dell-smo8800.c | 1 +
firmware/Makefile | 7 +-
include/asm-generic/ranges.h | 70 +++
include/asm-generic/sections.h | 306 ++++++++++-
include/asm-generic/tables.h | 70 +++
include/asm-generic/vmlinux.lds.h | 66 +--
include/linux/compiler.h | 2 +-
include/linux/dynamic_debug.h | 5 +-
include/linux/init.h | 20 +-
include/linux/jump_label.h | 10 +-
include/linux/kprobes.h | 8 +-
include/linux/ranges.h | 54 ++
include/linux/sections.h | 123 +++++
include/linux/tables.h | 597 +++++++++++++++++++++
kernel/jump_label.c | 17 +-
kernel/kprobes.c | 17 +-
lib/dynamic_debug.c | 13 +-
scripts/Makefile | 1 +
scripts/Makefile.build | 4 +-
scripts/Makefile.clean | 1 +
scripts/Makefile.lib | 12 +
scripts/Makefile.modpost | 2 +-
scripts/mod/Makefile | 2 +
scripts/mod/modpost.c | 8 +-
scripts/{module-common.lds => module-common.lds.S} | 6 +
scripts/recordmcount.c | 7 +-
scripts/recordmcount.pl | 2 +-
tools/include/linux/sections.h | 13 +
tools/objtool/special.c | 8 +-
164 files changed, 2241 insertions(+), 205 deletions(-)
create mode 100644 Documentation/DocBook/linker-tables.tmpl
create mode 100644 Documentation/DocBook/sections.tmpl
create mode 100644 arch/alpha/include/asm/ranges.h
create mode 100644 arch/alpha/include/asm/sections.h
create mode 100644 arch/alpha/include/asm/tables.h
create mode 100644 arch/arc/include/asm/ranges.h
create mode 100644 arch/arc/include/asm/tables.h
create mode 100644 arch/arm/include/asm/ranges.h
create mode 100644 arch/arm/include/asm/tables.h
create mode 100644 arch/arm64/include/asm/ranges.h
create mode 100644 arch/arm64/include/asm/sections.h
create mode 100644 arch/arm64/include/asm/tables.h
create mode 100644 arch/avr32/include/asm/ranges.h
create mode 100644 arch/avr32/include/asm/sections.h
create mode 100644 arch/avr32/include/asm/tables.h
create mode 100644 arch/blackfin/include/asm/ranges.h
create mode 100644 arch/blackfin/include/asm/tables.h
create mode 100644 arch/c6x/include/asm/ranges.h
create mode 100644 arch/c6x/include/asm/tables.h
create mode 100644 arch/cris/include/asm/ranges.h
create mode 100644 arch/cris/include/asm/sections.h
create mode 100644 arch/cris/include/asm/tables.h
create mode 100644 arch/frv/include/asm/ranges.h
create mode 100644 arch/frv/include/asm/tables.h
create mode 100644 arch/h8300/include/asm/ranges.h
create mode 100644 arch/h8300/include/asm/sections.h
create mode 100644 arch/h8300/include/asm/tables.h
create mode 100644 arch/hexagon/include/asm/ranges.h
create mode 100644 arch/hexagon/include/asm/sections.h
create mode 100644 arch/hexagon/include/asm/tables.h
create mode 100644 arch/ia64/include/asm/ranges.h
create mode 100644 arch/ia64/include/asm/tables.h
create mode 100644 arch/m32r/include/asm/ranges.h
create mode 100644 arch/m32r/include/asm/sections.h
create mode 100644 arch/m32r/include/asm/tables.h
create mode 100644 arch/m68k/include/asm/ranges.h
create mode 100644 arch/m68k/include/asm/sections.h
create mode 100644 arch/m68k/include/asm/tables.h
create mode 100644 arch/metag/include/asm/ranges.h
create mode 100644 arch/metag/include/asm/sections.h
create mode 100644 arch/metag/include/asm/tables.h
create mode 100644 arch/microblaze/include/asm/ranges.h
create mode 100644 arch/microblaze/include/asm/tables.h
create mode 100644 arch/mips/include/asm/ranges.h
create mode 100644 arch/mips/include/asm/sections.h
create mode 100644 arch/mips/include/asm/tables.h
create mode 100644 arch/mn10300/include/asm/ranges.h
create mode 100644 arch/mn10300/include/asm/sections.h
create mode 100644 arch/mn10300/include/asm/tables.h
create mode 100644 arch/nios2/include/asm/ranges.h
create mode 100644 arch/nios2/include/asm/sections.h
create mode 100644 arch/nios2/include/asm/tables.h
create mode 100644 arch/openrisc/include/asm/ranges.h
create mode 100644 arch/openrisc/include/asm/sections.h
create mode 100644 arch/openrisc/include/asm/tables.h
create mode 100644 arch/parisc/include/asm/ranges.h
create mode 100644 arch/parisc/include/asm/tables.h
create mode 100644 arch/powerpc/include/asm/ranges.h
create mode 100644 arch/powerpc/include/asm/tables.h
create mode 100644 arch/s390/include/asm/ranges.h
create mode 100644 arch/s390/include/asm/tables.h
create mode 100644 arch/score/include/asm/ranges.h
create mode 100644 arch/score/include/asm/sections.h
create mode 100644 arch/score/include/asm/tables.h
create mode 100644 arch/sh/include/asm/ranges.h
create mode 100644 arch/sh/include/asm/tables.h
create mode 100644 arch/sparc/include/asm/ranges.h
create mode 100644 arch/sparc/include/asm/tables.h
create mode 100644 arch/tile/include/asm/ranges.h
create mode 100644 arch/tile/include/asm/tables.h
create mode 100644 arch/um/include/asm/ranges.h
create mode 100644 arch/um/include/asm/tables.h
create mode 100644 arch/unicore32/include/asm/ranges.h
create mode 100644 arch/unicore32/include/asm/sections.h
create mode 100644 arch/unicore32/include/asm/tables.h
create mode 100644 arch/x86/include/asm/ranges.h
create mode 100644 arch/x86/include/asm/tables.h
create mode 100644 arch/xtensa/include/asm/ranges.h
create mode 100644 arch/xtensa/include/asm/sections.h
create mode 100644 arch/xtensa/include/asm/tables.h
create mode 100644 include/asm-generic/ranges.h
create mode 100644 include/asm-generic/tables.h
create mode 100644 include/linux/ranges.h
create mode 100644 include/linux/sections.h
create mode 100644 include/linux/tables.h
rename scripts/{module-common.lds => module-common.lds.S} (80%)
create mode 100644 tools/include/linux/sections.hSignature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 1/13 x86: remove LTO_REFERENCE_INITCALL()
The setup for LTO never made it upstream, and although this has some users, this is now really old stuff for a gcc 4.7 LTO problem. We know that at least LTO_REFERENCE_INITCALL() work around can be removed if LTO is not supported on v4.7 anymore.
As per Andi the DISABLE_LTO and LTO_CFLAGS are still neeeded though.
v3: added to this series, removing LTO_REFERENCE_INITCALL()
justifies that other future similar macros do not need a respective LTO_REFERENCE_INITCALL() on them therefore simplifying new code.
--- include/linux/init.h | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-)
include/linux/init.h +1 -19
@@ -151,23 +151,6 @@ extern bool initcall_debug;#ifndef __ASSEMBLY__ -#ifdef CONFIG_LTO -/* Work around a LTO gcc problem: when there is no reference to a variable -* in a module it will be moved to the end of the program. This causes -* reordering of initcalls which the kernel does not like. -* Add a dummy reference function to avoid this. The function is -* deleted by the linker. -*/ -#define LTO_REFERENCE_INITCALL(x) \ - ; /* yes this is needed */ \ - static __used __exit void *reference_##x(void) \ - { \ - return &x; \ - } -#else -#define LTO_REFERENCE_INITCALL (x) -#endif -/* initcalls are now grouped by functionality into separate * subsections. Ordering inside the subsections is determined * by link order.
@@ -180,8 +163,7 @@ extern bool initcall_debug;#define __define_initcall (fn, id) \ static initcall_t __initcall_##fn##id __used \ - __attribute__((__section__(".initcall" #id ".init"))) = fn; \ - LTO_REFERENCE_INITCALL(__initcall_##fn##id) + __attribute__((__section__(".initcall" #id ".init"))) = fn;/* * Early initcalls run before initializing SMP.
Signature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 2/13 dell-smo8800: include uaccess.h
In reply to Luis R. Rodriguezsections.h is currently included and it provides dell-smo8800 with what it needs, an upcoming change will decouple uaccess.h from sections.h. This driver needs to explicitly require uaccess.h before this change.
v3: new to this series -- needed due to collateral of the split of
old linker tables from tables.h into 3 files: sections.h, ranges.h and tables.h
--- drivers/platform/x86/dell-smo8800.c | 1 + 1 file changed, 1 insertion(+)
drivers/platform/x86/dell-smo8800.c +1 -0
@@ -24,6 +24,7 @@#include <linux/acpi.h> #include <linux/interrupt.h> #include <linux/miscdevice.h> +#include <linux/uaccess.h> struct smo8800_device {u32 irq;/* acpi device irq */
Signature · 1 line
2.8.4
Re: [RFC v3 02/13] dell-smo8800: include uaccess.h
Quoted 20 lines · On Friday 22 July 2016 23:24:36 Luis R. Rodriguez wrote:
sections.his currently included and it provides dell-smo8800 with what it needs, an upcoming change will decoupleuaccess.hfromsections.h. This driver needs to explicitly requireuaccess.hbefore this change.v3: new to this series -- needed due to collateral of the split of
old linker tables fromtables.hinto 3 files:sections.h,ranges.handtables.hSigned-off-by Luis R. Rodriguez <[email protected]>--- drivers/platform/x86/dell-smo8800.c | 1 + 1 file changed, 1 insertion(+)(quoted diff) +0
-0
b/drivers/platform/x86/dell-smo8800.cindex0aec4fd4c48e..37e646034ef8100644
drivers/platform/x86/dell-smo8800.c line 30
Quoted 7 lines
drivers/platform/x86/dell-smo8800.c +1
-0@@ -24,6 +24,7 @@#include <linux/acpi.h> #include <linux/interrupt.h> #include <linux/miscdevice.h> +#include <linux/uaccess.h> struct smo8800_device {u32 irq;/* acpi device irq */
This is trivial change for dell-smo8800, so you can add my Reviewed-by.
Signature · 2 lines
Pali Rohár [email protected]
Luis R. Rodriguez
maintainerRFC v3 3/13 scripts/module-common.lds: enable generation
In reply to Luis R. Rodriguezscripts/module-common.lds is currently pretty static, in the future this may change and we will want access to kernel macros to help expands certain areas. To get access to use macros we need to generate module-common.lds from module-common.lds.S, for now though only enable the generation. We'll later expand on this as needed.
Since this file is now generated add it to .gitignore.
v3: new to this series
---
.gitignore | 2 ++
Makefile | 6 +++++-
scripts/Makefile.modpost | 2 +-
scripts/{module-common.lds => module-common.lds.S} | 0
4 files changed, 8 insertions(+), 2 deletions(-)
rename scripts/{module-common.lds => module-common.lds.S} (100%).gitignore +2 -0
@@ -113,3 +113,5 @@ all.config # Kdevelop4 *.kdev4 + +scripts/module-common.lds
Makefile +5 -1
@@ -408,6 +408,10 @@ KBUILD_AFLAGS_MODULE := -DMODULE KBUILD_CFLAGS_MODULE := -DMODULE KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds +$(srctree)/scripts/module-common.lds: $(srctree)/scripts/module-common.lds.S + $(Q)$(CC) $(CFLAGS) $(INCLUDES) $(LINUXINCLUDE) -E -P \ + -D__ASSEMBLY__ -DLINKER_SCRIPT -o $@ $< + # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
@@ -1178,7 +1182,7 @@ all: modules # using awk while concatenating to the final file. PHONY += modules -modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) modules.builtin +modules: $(srctree)/scripts/module-common.lds $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) modules.builtin $(Q)$(AWK) '!x[$$0]++' $(vmlinux-dirs:%=$(objtree)/%/modules.order) > $(objtree)/modules.order @$(kecho) ' Building modules, stage 2.'; $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
scripts/Makefile.modpost +1 -1
@@ -121,7 +121,7 @@ quiet_cmd_ld_ko_o = LD [M] $@ $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \ -o $@ $(filter-out FORCE,$^) -$(modules): %.ko :%.o %.mod.o FORCE +$(modules): %.ko : $(srctree)/scripts/module-common.lds %.o %.mod.o FORCE $(call if_changed,ld_ko_o) targets += $(modules)
scripts/module-common.lds.S renamed from scripts/module-common.lds +0 -0
Signature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 4/13 sections.h: guard against asm and linker script
In reply to Luis R. RodriguezWe'll later add some generic helpers for use in the linker scripts and some generic asm code for all architectures. To do that we'll first need to guard against linker script and asm code.
On x86 uaccess.h has a struct which is used as part of a section, move that to sections.h as we otherwise have no need for uaccess.h on sections.h
v3: new to this series, needed due to the collateral of the split of
tables.h into 3 files: tables.h, ranges.h and sections.h, the need to guard sections.h is due to the fact that sections.h is already included and expanded considerably in certain architectures.
--- arch/arm/include/asm/sections.h | 2 ++ arch/blackfin/include/asm/sections.h | 4 ++++ arch/ia64/include/asm/sections.h | 7 +++++-- arch/powerpc/include/asm/sections.h | 11 ++++++----- arch/sh/include/asm/sections.h | 2 ++ arch/sparc/include/asm/sections.h | 4 ++++ arch/tile/include/asm/sections.h | 4 ++++ arch/x86/include/asm/sections.h | 23 ++++++++++++++++++++++- arch/x86/include/asm/uaccess.h | 18 +----------------- include/asm-generic/sections.h | 4 ++++ 10 files changed, 54 insertions(+), 25 deletions(-)
arch/arm/include/asm/sections.h +2 -0
@@ -3,6 +3,8 @@#include <asm-generic/sections.h> +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__)extern char _exiprom[]; +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ #endif /* _ASM_ARM_SECTIONS_H */
arch/blackfin/include/asm/sections.h +4 -0
@@ -7,6 +7,8 @@#ifndef _BLACKFIN_SECTIONS_H#define _BLACKFIN_SECTIONS_H +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) +/* only used when MTD_UCLINUX */ extern unsigned long memory_mtd_start, memory_mtd_end, mtd_size;
@@ -62,6 +64,8 @@ static inline int arch_is_kernel_data(unsigned long addr) }#define arch_is_kernel_data (addr) arch_is_kernel_data(addr) +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ +#include <asm-generic/sections.h> #endif
arch/ia64/include/asm/sections.h +5 -2
@@ -6,9 +6,12 @@* David Mosberger-Tang <[email protected]> */ +#include <asm-generic/sections.h> + +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) +#include <linux/elf.h> #include <linux/uaccess.h> -#include <asm-generic/sections.h> extern char __phys_per_cpu_start[];#ifdef CONFIG_SMP
@@ -37,6 +40,6 @@ static inline void *dereference_function_descriptor(void *ptr)return ptr; } +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ #endif /* _ASM_IA64_SECTIONS_H */ -
arch/powerpc/include/asm/sections.h +6 -5
@@ -1,11 +1,12 @@#ifndef _ASM_POWERPC_SECTIONS_H#define _ASM_POWERPC_SECTIONS_H -#ifdef __KERNEL__ -#include <linux/elf.h> -#include <linux/uaccess.h> #include <asm-generic/sections.h> +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) + +#include <linux/elf.h> +#include <linux/uaccess.h> #ifdef __powerpc64__extern char __start_interrupts[];
@@ -75,7 +76,7 @@ static inline void *dereference_function_descriptor(void *ptr) }#endif /* PPC64_ELF_ABI_v1 */ -#endif +#endif /* __powerpc64__ */ +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ -#endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_SECTIONS_H */
arch/sh/include/asm/sections.h +2 -0
@@ -3,9 +3,11 @@#include <asm-generic/sections.h> +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__)extern long __machvec_start, __machvec_end;extern char __uncached_start, __uncached_end;extern char __start_eh_frame[], __stop_eh_frame[]; +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ #endif /* __ASM_SH_SECTIONS_H */
arch/sparc/include/asm/sections.h +4 -0
@@ -4,10 +4,14 @@/* nothing to see, move along */ #include <asm-generic/sections.h> +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) +/* sparc entry point */ extern char _start[];extern char __leon_1insn_patch[];extern char __leon_1insn_patch_end[]; +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ +#endif
arch/tile/include/asm/sections.h +4 -0
@@ -19,6 +19,8 @@#include <asm-generic/sections.h> +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) +/* Write-once data is writable only till the end of initialization. */ extern char __w1data_begin[], __w1data_end[];
@@ -44,4 +46,6 @@ static inline int arch_is_kernel_data(unsigned long addr) addr < (unsigned long )_end; } +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ +#endif /* _ASM_TILE_SECTIONS_H */
arch/x86/include/asm/sections.h +22 -1
@@ -2,13 +2,34 @@#define _ASM_X86_SECTIONS_H#include <asm-generic/sections.h> -#include <asm/uaccess.h> + +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__)extern char __brk_base[], __brk_limit[]; + +/* +* The exception table consists of triples of addresses relative to the +* exception table entry itself. The first address is of an instruction +* that is allowed to fault, the second is the target at which the program +* should continue. The third is a handler function to deal with the fault +* caused by the instruction in the first field. +* +* All the routines below use bits of fixup code that are out of line +* with the main instruction path. This means when everything is well, +* we don't even have to jump over them. Further, they do not intrude +* on our cache or tlb entries. +*/ + +struct exception_table_entry { +int insn, fixup, handler; +}; +extern struct exception_table_entry __stop___ex_table[];#if defined(CONFIG_X86_64 )extern char __end_rodata_hpage_align[];#endif +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ +#endif /* _ASM_X86_SECTIONS_H */
arch/x86/include/asm/uaccess.h +1 -17
@@ -8,6 +8,7 @@#include <linux/kasan-checks.h> #include <linux/thread_info.h> #include <linux/string.h> +#include <asm/sections.h> #include <asm/asm.h> #include <asm/page.h> #include <asm/smap.h>
@@ -90,23 +91,6 @@ static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, un#define access_ok (type, addr, size) \ likely(!__range_not_ok(addr, size, user_addr_max())) -/* -* The exception table consists of triples of addresses relative to the -* exception table entry itself. The first address is of an instruction -* that is allowed to fault, the second is the target at which the program -* should continue. The third is a handler function to deal with the fault -* caused by the instruction in the first field. -* -* All the routines below use bits of fixup code that are out of line -* with the main instruction path. This means when everything is well, -* we don't even have to jump over them. Further, they do not intrude -* on our cache or tlb entries. -*/ - -struct exception_table_entry { -int insn, fixup, handler; -}; -#define ARCH_HAS_RELATIVE_EXTABLE #define swap_ex_entry_fixup (a, b, tmp, delta) \
include/asm-generic/sections.h +4 -0
@@ -1,6 +1,8 @@#ifndef _ASM_GENERIC_SECTIONS_H_#define _ASM_GENERIC_SECTIONS_H_ +#if defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) +/* References to section boundaries */ #include <linux/compiler.h>
@@ -128,4 +130,6 @@ static inline bool init_section_intersects(void *virt, size_t size)return memory_intersects (__init_begin, __init_end, virt, size); } +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) && !defined(__ASSEMBLY__) */ +#endif /* _ASM_GENERIC_SECTIONS_H_ */
Signature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 5/13 sections.h: add sections header to collect all section info
In reply to Luis R. RodriguezLinux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place and provide helpers to build custom Linux sections.
We are now generalizing sections.h in code to enable avoiding modifying the linker when we want to add new custom Linux sections but to make this generally useful we need to ensure all architectures also have their own asm/sections.h, this is now also used by the custom series of helpers to an architecture's linker script:
asm-generic/vmlinux.lds.h.
v3:
o add missing sections.h for architectures that did not have it
o move generic sections to asm-generic/sections.h
o add generic asm helpers section_type(), section_type_asmtype(), push_section_type() -- these helpers enable easy use for for later declaring and using of custom linux sections using more standard APIs in both C code, asm code (C asm calls, or asm files), enabling future standardized section types to be more immediately accessible to asm code, not just C code. Note for ASM_CMD_SEP we use by default "\n", architectures needed to override can do so on their own sections.h prior to inclusion of asm-generic/sections.h
--- Documentation/DocBook/Makefile | 3 +- Documentation/DocBook/sections.tmpl | 112 +++++++++++++ arch/alpha/include/asm/sections.h | 6 + arch/arm64/include/asm/sections.h | 6 + arch/avr32/include/asm/sections.h | 6 + arch/cris/include/asm/sections.h | 6 + arch/h8300/include/asm/sections.h | 6 + arch/hexagon/include/asm/sections.h | 6 + arch/m32r/include/asm/sections.h | 6 + arch/m68k/include/asm/sections.h | 6 + arch/metag/include/asm/sections.h | 6 + arch/mips/include/asm/sections.h | 6 + arch/mn10300/include/asm/sections.h | 6 + arch/nios2/include/asm/sections.h | 6 + arch/openrisc/include/asm/sections.h | 6 + arch/score/include/asm/sections.h | 6 + arch/unicore32/include/asm/sections.h | 6 + arch/xtensa/include/asm/sections.h | 6 + include/asm-generic/sections.h | 300 ++++++++++++++++++++++++++++++++++ include/asm-generic/vmlinux.lds.h | 27 +-- include/linux/sections.h | 123 ++++++++++++++ 21 files changed, 647 insertions(+), 14 deletions(-) create mode 100644 Documentation/DocBook/sections.tmpl create mode 100644 arch/alpha/include/asm/sections.h create mode 100644 arch/arm64/include/asm/sections.h create mode 100644 arch/avr32/include/asm/sections.h create mode 100644 arch/cris/include/asm/sections.h create mode 100644 arch/h8300/include/asm/sections.h create mode 100644 arch/hexagon/include/asm/sections.h create mode 100644 arch/m32r/include/asm/sections.h create mode 100644 arch/m68k/include/asm/sections.h create mode 100644 arch/metag/include/asm/sections.h create mode 100644 arch/mips/include/asm/sections.h create mode 100644 arch/mn10300/include/asm/sections.h create mode 100644 arch/nios2/include/asm/sections.h create mode 100644 arch/openrisc/include/asm/sections.h create mode 100644 arch/score/include/asm/sections.h create mode 100644 arch/unicore32/include/asm/sections.h create mode 100644 arch/xtensa/include/asm/sections.h create mode 100644 include/linux/sections.h
Documentation/DocBook/Makefile +2 -1
@@ -17,7 +17,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ tracepoint.xml media_api.xml w1.xml \ - writing_musb_glue_layer.xml crypto-API.xml iio.xml + writing_musb_glue_layer.xml crypto-API.xml iio.xml \ + sections.xml include Documentation/DocBook/media/Makefile
Documentation/DocBook/sections.tmpl new file +112 -0
112 lines not on this page · raw message
arch/alpha/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ALPHA_SECTIONS_H +#define _ASM_ALPHA_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_ALPHA_SECTIONS_H */
arch/arm64/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARM64_SECTIONS_H +#define _ASM_ARM64_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_ARM64_SECTIONS_H */
arch/avr32/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_AVR32_SECTIONS_H +#define _ASM_AVR32_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_AVR32_SECTIONS_H */
arch/cris/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_CRIS_SECTIONS_H +#define _ASM_CRIS_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_CRIS_SECTIONS_H */
arch/h8300/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_H8300_SECTIONS_H +#define _ASM_H8300_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_H8300_SECTIONS_H */
arch/hexagon/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_HEXAGON_SECTIONS_H +#define _ASM_HEXAGON_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_HEXAGON_SECTIONS_H */
arch/m32r/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_M32R_SECTIONS_H +#define _ASM_M32R_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_M32R_SECTIONS_H */
arch/m68k/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_M68K_SECTIONS_H +#define _ASM_M68K_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_M68K_SECTIONS_H */
arch/metag/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_METAG_SECTIONS_H +#define _ASM_METAG_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_METAG_SECTIONS_H */
arch/mips/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MIPS_SECTIONS_H +#define _ASM_MIPS_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_MIPS_SECTIONS_H */
arch/mn10300/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MN10300_SECTIONS_H +#define _ASM_MN10300_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_MN10300_SECTIONS_H */
arch/nios2/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_NIOS2_SECTIONS_H +#define _ASM_NIOS2_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_NIOS2_SECTIONS_H */
arch/openrisc/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_OPENRISC_SECTIONS_H +#define _ASM_OPENRISC_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_OPENRISC_SECTIONS_H */
arch/score/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SCORE_SECTIONS_H +#define _ASM_SCORE_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_SCORE_SECTIONS_H */
arch/unicore32/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_UNICORE32_SECTIONS_H +#define _ASM_UNICORE32_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_UNICORE32_SECTIONS_H */
arch/xtensa/include/asm/sections.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_XTENSA_SECTIONS_H +#define _ASM_XTENSA_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_XTENSA_SECTIONS_H */
include/asm-generic/sections.h +300 -0
306 lines not on this page · raw message
include/asm-generic/vmlinux.lds.h +14 -13
@@ -55,6 +55,7 @@#endif #include <linux/export.h> +#include <asm/sections.h> /* Align . to a 8 byte boundary equals to maximum function alignment. */ #define ALIGN_FUNCTION () . = ALIGN(8)
@@ -198,8 +199,8 @@/* .data section */ #define DATA_DATA \ - *(.data) \ - *(.ref.data) \ + *(SECTION_DATA) \ + *(SECTION_REF_DATA) \ *(.data..shared_aligned)/* percpu related */ \ MEM_KEEP(init.data) \MEM_KEEP (exit.data) \
@@ -262,9 +263,9 @@*/ #define RO_DATA_SECTION (align) \ . = ALIGN((align)); \ - .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ + SECTION_RODATA : AT(ADDR(SECTION_RODATA) - LOAD_OFFSET) { \ VMLINUX_SYMBOL(__start_rodata) = .; \ - *(.rodata) *(.rodata.*) \ + *(SECTION_RODATA) *(SECTION_ALL(SECTION_RODATA)) \ RO_AFTER_INIT_DATA/* Read only after init */ \ *(__vermagic)/* Kernel version magic */ \ . = ALIGN(8); \
@@ -394,7 +395,7 @@ \/* __*init sections */ \ __init_rodata : AT(ADDR(__init_rodata) - LOAD_OFFSET) { \ - *(.ref.rodata) \ + *(SECTION_REF_RODATA ) \ MEM_KEEP(init.rodata) \MEM_KEEP (exit.rodata) \ } \
@@ -432,8 +433,8 @@* during second ld run in second ld pass when generating System.map */ #define TEXT_TEXT \ ALIGN_FUNCTION(); \ - *(.text.hot .text .text.fixup .text.unlikely) \ - *(.ref.text) \ + *(.text.hot SECTION_TEXT .text.fixup .text.unlikely) \ + *(SECTION_REF) \ MEM_KEEP(init.text) \ MEM_KEEP(exit.text) \
@@ -527,11 +528,11 @@/* init and exit section handling */ #define INIT_DATA \ - *(.init.data) \ + *(SECTION_INIT_DATA) \ MEM_DISCARD(init.data) \ KERNEL_CTORS() \ MCOUNT_REC() \ - *(.init.rodata) \ + *(SECTION_INIT_RODATA) \ FTRACE_EVENTS() \ TRACE_SYSCALLS() \ KPROBE_BLACKLIST() \
@@ -549,24 +550,24 @@ EARLYCON_TABLE()#define INIT_TEXT \ - *(.init.text) \ + *(SECTION_INIT) \ *(.text.startup) \ MEM_DISCARD(init.text)#define EXIT_DATA \ - *(.exit.data) \ + *(SECTION_EXIT_DATA) \ *(.fini_array) \ *(.dtors) \ MEM_DISCARD(exit.data) \ MEM_DISCARD(exit.rodata)#define EXIT_TEXT \ - *(.exit.text) \ + *(SECTION_EXIT) \ *(.text.exit) \ MEM_DISCARD(exit.text)#define EXIT_CALL \ - *(.exitcall.exit) + *(SECTION_EXIT_CALL)/* * bss (Block Started by Symbol) - uninitialized data
include/linux/sections.h new file +123 -0
123 lines not on this page · raw message
Signature · 1 line
2.8.4
Re: [RFC v3 05/13] sections.h: add sections header to collect all section info
Hi Luis,
Quoted 23 lines · On Friday 22 July 2016 14:24:39 Luis R. Rodriguez wrote:
arch/alpha/include/asm/sections.h | 6 + arch/arm64/include/asm/sections.h | 6 + arch/avr32/include/asm/sections.h | 6 + arch/cris/include/asm/sections.h | 6 + arch/h8300/include/asm/sections.h | 6 + arch/hexagon/include/asm/sections.h | 6 + arch/m32r/include/asm/sections.h | 6 + arch/m68k/include/asm/sections.h | 6 + arch/metag/include/asm/sections.h | 6 + arch/mips/include/asm/sections.h | 6 + arch/mn10300/include/asm/sections.h | 6 + arch/nios2/include/asm/sections.h | 6 + arch/openrisc/include/asm/sections.h | 6 + arch/score/include/asm/sections.h | 6 + arch/unicore32/include/asm/sections.h | 6 + arch/xtensa/include/asm/sections.h | 6 +arch/alpha/include/asm/sections.h new file +0
-0
arch/alpha/include/asm/sections.h line 6
Quoted 6 lines
arch/alpha/include/asm/sections.h new file +6
-0@@ -0,0 +1,6 @@ +#ifndef _ASM_ALPHA_SECTIONS_H +#define _ASM_ALPHA_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_ALPHA_SECTIONS_H */
Any particular reason not to use generic-y in the Kbuild files for sections.h, ranges.h, and tables.h?
Cheers
James
Luis R. Rodriguez
maintainerRe: [RFC v3 05/13] sections.h: add sections header to collect all section info
Quoted 20 lines · James Hogan
Hi Luis,
Quoted 16 lines · On Friday 22 July 2016 14:24:39 Luis R. Rodriguez wrote:
arch/alpha/include/asm/sections.h | 6 + arch/arm64/include/asm/sections.h | 6 + arch/avr32/include/asm/sections.h | 6 + arch/cris/include/asm/sections.h | 6 + arch/h8300/include/asm/sections.h | 6 + arch/hexagon/include/asm/sections.h | 6 + arch/m32r/include/asm/sections.h | 6 + arch/m68k/include/asm/sections.h | 6 + arch/metag/include/asm/sections.h | 6 + arch/mips/include/asm/sections.h | 6 + arch/mn10300/include/asm/sections.h | 6 + arch/nios2/include/asm/sections.h | 6 + arch/openrisc/include/asm/sections.h | 6 + arch/score/include/asm/sections.h | 6 + arch/unicore32/include/asm/sections.h | 6 + arch/xtensa/include/asm/sections.h | 6 +
Quoted 15 lines
arch/alpha/include/asm/sections.h line 6
Quoted 12 lines
arch/alpha/include/asm/sections.h new file +6
-0@@ -0,0 +1,6 @@ +#ifndef _ASM_ALPHA_SECTIONS_H +#define _ASM_ALPHA_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_ALPHA_SECTIONS_H */ Any particular reason not to use generic-y in the
Kbuildfiles forsections.h,ranges.h, andtables.h?
I was just not aware of that, thanks, will do this in the next iteration!
Luis
Steven Rostedt
reviewerRe: [RFC v3 05/13] sections.h: add sections header to collect all section info
In reply to James HoganQuoted 4 lines · On Fri, 22 Jul 2016 22:37:16 +0100 James Hogan <[email protected]> wrote:
Quoted 4 lines
arch/alpha/include/asm/sections.h new file +1
-0@@ -0,0 +1,6 @@ +#ifndef _ASM_ALPHA_SECTIONS_H
Quoted 8 lines
arch/alpha/include/asm/sections.h line 6
Quoted 5 lines
arch/alpha/include/asm/sections.h new file +5
-0+#define _ASM_ALPHA_SECTIONS_H + +#include <asm-generic/sections.h> + +#endif /* _ASM_ALPHA_SECTIONS_H */ Any particular reason not to use generic-y in the
Kbuildfiles forsections.h,ranges.h, andtables.h?
One of my TODOs is to simplify that process. That is, to get rid of the having to add it to all archs and get rid of the Kbuild file altogether.
-- Steve
Luis R. Rodriguez
maintainerRFC v3 6/13 ranges.h: add helpers to build and identify Linux section ranges
In reply to Luis R. RodriguezSection ranges are on one of the types of custom sections types used in Linux. This provides a series of helpers for defining them and using them. Most importantly this also enables us to avoid modifying the linker script when we add new section range.
It turns out a lot of custom sections are actually section ranges, and these are typically spelled out in their architecture specific asm/sections.h file -- we anable architectures to override what asm is used for section ranges but start by defult trusting the asm-generic version all around.
v3: new in this series, uses copyleft-next
--- arch/alpha/include/asm/ranges.h | 6 ++++ arch/arc/include/asm/ranges.h | 6 ++++ arch/arm/include/asm/ranges.h | 6 ++++ arch/arm64/include/asm/ranges.h | 6 ++++ arch/avr32/include/asm/ranges.h | 6 ++++ arch/blackfin/include/asm/ranges.h | 6 ++++ arch/c6x/include/asm/ranges.h | 6 ++++ arch/cris/include/asm/ranges.h | 6 ++++ arch/frv/include/asm/ranges.h | 6 ++++ arch/h8300/include/asm/ranges.h | 6 ++++ arch/hexagon/include/asm/ranges.h | 6 ++++ arch/ia64/include/asm/ranges.h | 6 ++++ arch/m32r/include/asm/ranges.h | 6 ++++ arch/m68k/include/asm/ranges.h | 6 ++++ arch/metag/include/asm/ranges.h | 6 ++++ arch/microblaze/include/asm/ranges.h | 6 ++++ arch/mips/include/asm/ranges.h | 6 ++++ arch/mn10300/include/asm/ranges.h | 6 ++++ arch/nios2/include/asm/ranges.h | 6 ++++ arch/openrisc/include/asm/ranges.h | 6 ++++ arch/parisc/include/asm/ranges.h | 6 ++++ arch/powerpc/include/asm/ranges.h | 6 ++++ arch/s390/include/asm/ranges.h | 6 ++++ arch/score/include/asm/ranges.h | 6 ++++ arch/sh/include/asm/ranges.h | 6 ++++ arch/sparc/include/asm/ranges.h | 6 ++++ arch/tile/include/asm/ranges.h | 6 ++++ arch/um/include/asm/ranges.h | 6 ++++ arch/unicore32/include/asm/ranges.h | 6 ++++ arch/x86/include/asm/ranges.h | 6 ++++ arch/xtensa/include/asm/ranges.h | 6 ++++ include/asm-generic/ranges.h | 70 ++++++++++++++++++++++++++++++++++++ include/linux/ranges.h | 54 ++++++++++++++++++++++++++++ 33 files changed, 310 insertions(+) create mode 100644 arch/alpha/include/asm/ranges.h create mode 100644 arch/arc/include/asm/ranges.h create mode 100644 arch/arm/include/asm/ranges.h create mode 100644 arch/arm64/include/asm/ranges.h create mode 100644 arch/avr32/include/asm/ranges.h create mode 100644 arch/blackfin/include/asm/ranges.h create mode 100644 arch/c6x/include/asm/ranges.h create mode 100644 arch/cris/include/asm/ranges.h create mode 100644 arch/frv/include/asm/ranges.h create mode 100644 arch/h8300/include/asm/ranges.h create mode 100644 arch/hexagon/include/asm/ranges.h create mode 100644 arch/ia64/include/asm/ranges.h create mode 100644 arch/m32r/include/asm/ranges.h create mode 100644 arch/m68k/include/asm/ranges.h create mode 100644 arch/metag/include/asm/ranges.h create mode 100644 arch/microblaze/include/asm/ranges.h create mode 100644 arch/mips/include/asm/ranges.h create mode 100644 arch/mn10300/include/asm/ranges.h create mode 100644 arch/nios2/include/asm/ranges.h create mode 100644 arch/openrisc/include/asm/ranges.h create mode 100644 arch/parisc/include/asm/ranges.h create mode 100644 arch/powerpc/include/asm/ranges.h create mode 100644 arch/s390/include/asm/ranges.h create mode 100644 arch/score/include/asm/ranges.h create mode 100644 arch/sh/include/asm/ranges.h create mode 100644 arch/sparc/include/asm/ranges.h create mode 100644 arch/tile/include/asm/ranges.h create mode 100644 arch/um/include/asm/ranges.h create mode 100644 arch/unicore32/include/asm/ranges.h create mode 100644 arch/x86/include/asm/ranges.h create mode 100644 arch/xtensa/include/asm/ranges.h create mode 100644 include/asm-generic/ranges.h create mode 100644 include/linux/ranges.h
arch/alpha/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ALPHA_RANGES_H +#define _ASM_ALPHA_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_ALPHA_RANGES_H */
arch/arc/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARC_RANGES_H +#define _ASM_ARC_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_ARC_RANGES_H */
arch/arm/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARM_RANGES_H +#define _ASM_ARM_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_ARM_RANGES_H */
arch/arm64/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARM64_RANGES_H +#define _ASM_ARM64_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_ARM64_RANGES_H */
arch/avr32/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_AVR32_RANGES_H +#define _ASM_AVR32_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_AVR32_RANGES_H */
arch/blackfin/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_BLACKFIN_RANGES_H +#define _ASM_BLACKFIN_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_BLACKFIN_RANGES_H */
arch/c6x/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_C6X_RANGES_H +#define _ASM_C6X_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_C6X_RANGES_H */
arch/cris/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_CRIS_RANGES_H +#define _ASM_CRIS_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_CRIS_RANGES_H */
arch/frv/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_FRV_RANGES_H +#define _ASM_FRV_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_FRV_RANGES_H */
arch/h8300/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_H8300_RANGES_H +#define _ASM_H8300_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_H8300_RANGES_H */
arch/hexagon/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_HEXAGON_RANGES_H +#define _ASM_HEXAGON_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_HEXAGON_RANGES_H */
arch/ia64/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_IA64_RANGES_H +#define _ASM_IA64_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_IA64_RANGES_H */
arch/m32r/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_M32R_RANGES_H +#define _ASM_M32R_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_M32R_RANGES_H */
arch/m68k/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_M68K_RANGES_H +#define _ASM_M68K_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_M68K_RANGES_H */
arch/metag/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_METAG_RANGES_H +#define _ASM_METAG_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_METAG_RANGES_H */
arch/microblaze/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MICROBLAZE_RANGES_H +#define _ASM_MICROBLAZE_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_MICROBLAZE_RANGES_H */
arch/mips/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MIPS_RANGES_H +#define _ASM_MIPS_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_MIPS_RANGES_H */
arch/mn10300/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MN10300_RANGES_H +#define _ASM_MN10300_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_MN10300_RANGES_H */
arch/nios2/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_NIOS2_RANGES_H +#define _ASM_NIOS2_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_NIOS2_RANGES_H */
arch/openrisc/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_OPENRISC_RANGES_H +#define _ASM_OPENRISC_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_OPENRISC_RANGES_H */
arch/parisc/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_PARISC_RANGES_H +#define _ASM_PARISC_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_PARISC_RANGES_H */
arch/powerpc/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_POWERPC_RANGES_H +#define _ASM_POWERPC_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_POWERPC_RANGES_H */
arch/s390/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_S390_RANGES_H +#define _ASM_S390_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_S390_RANGES_H */
arch/score/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SCORE_RANGES_H +#define _ASM_SCORE_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_SCORE_RANGES_H */
arch/sh/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SH_RANGES_H +#define _ASM_SH_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_SH_RANGES_H */
arch/sparc/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SPARC_RANGES_H +#define _ASM_SPARC_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_SPARC_RANGES_H */
arch/tile/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_TILE_RANGES_H +#define _ASM_TILE_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_TILE_RANGES_H */
arch/um/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_UM_RANGES_H +#define _ASM_UM_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_UM_RANGES_H */
arch/unicore32/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_UNICORE32_RANGES_H +#define _ASM_UNICORE32_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_UNICORE32_RANGES_H */
arch/x86/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_X86_RANGES_H +#define _ASM_X86_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_X86_RANGES_H */
arch/xtensa/include/asm/ranges.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_XTENSA_RANGES_H +#define _ASM_XTENSA_RANGES_H + +#include <asm-generic/ranges.h> + +#endif /* _ASM_XTENSA_RANGES_H */
include/asm-generic/ranges.h new file +70 -0
70 lines not on this page · raw message
include/linux/ranges.h new file +54 -0
54 lines not on this page · raw message
Signature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 7/13 tables.h: add linker table support
In reply to Luis R. RodriguezA linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker table solution so that a new linker table can be implemented by changing C code only. The Linux linker table was originally based on Michael Brown's iPXE's linker table solution but has been significantly modified to fit Linux's use in its integration.
The same philosophy is borrowed, extended and further simplified:
Linker tables enable an extremely light weight linker build time solution for feature ordering and selection, this can help to both simplify init sequences in a generic fashion and helps avoiding code bit-rotting when desirable.
Bit rotting avoidance is enabled by *granting the option* to force compilation of code and only enable linking object code in when specific features have been enabled. It accomplishes this by using linker sections, the lightweight feature ordering of code is enabled by taking advantage of the old binutils ld SORT() on features specific sections.
Contrary to iPXE's solution, which strives to force compilation of all features, Linux' solution strives to encourage usage of linker tables to force compilation of code *only on designated code*. Linker tables can be used without requiring one to force code compilation of features that use it though, to take advantage of the simplification of init sequences.
Linux code that uses linker tables *and* wishes to always require compilation but selectively linking must use new kbuild target object that helps accomplishes this, table-y. Linux code that uses linker tables but does not want to require forcing compilation can use the good 'ol obj-y targets.
Used commit 67a10ef000cb7 from iPXE upstream [0] as the starting point for development and evaluation of Linux's integration, further changes made and evaluation of different linker table options for Linux are available on the linker-table userspace tree [1].
[0] git://git.ipxe.org/ipxe.git
[1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
v3:
o addressed initial modular support test cases
o added generic asm macros so linker tables can be used in asm code / C asm calls
o section ranges are now split up into their own set of files
o use asm/sections.h instead of linux/sections.h for the linker script
o add a sections.h file for each architecture that was missing one, this is needed now as we'll be relying on sections.h for custom section types in code rather than custom architecture specific linker script hacks.
o full rewrite at this point, decided to pick copyleft-next license for this work
v2:
o modified completely to match feedback by community, made equivalent modifications to userspace solution. This is pretty much a complete rewrite of how we present and use linker tables. By using standard sections we no longer have to make custom linker script extensions for each new linker table solution, you just pick a linker table type by section type.
o extend documention considerably, including use of kdoc
o drop ICC hacks per popular request to ignore such issues for now
o use sections.h - this lets us streamline a clean use case of well documented sections. To help further with this make use of SECTION_TBL() to allow use of these in code and SECTION_TBL_ALL() on linker scripts, as well as SECTION_TBL_ALL_STR() on relocs.c when needed.
--- Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/linker-tables.tmpl | 166 +++++++++ Documentation/kbuild/makefiles.txt | 19 + arch/alpha/include/asm/tables.h | 6 + arch/arc/include/asm/tables.h | 6 + arch/arm/include/asm/tables.h | 6 + arch/arm64/include/asm/tables.h | 6 + arch/avr32/include/asm/tables.h | 6 + arch/blackfin/include/asm/tables.h | 6 + arch/c6x/include/asm/tables.h | 6 + arch/cris/include/asm/tables.h | 6 + arch/frv/include/asm/tables.h | 6 + arch/h8300/include/asm/tables.h | 6 + arch/hexagon/include/asm/tables.h | 6 + arch/ia64/include/asm/tables.h | 6 + arch/m32r/include/asm/tables.h | 6 + arch/m68k/include/asm/tables.h | 6 + arch/metag/include/asm/tables.h | 6 + arch/microblaze/include/asm/tables.h | 6 + arch/mips/include/asm/tables.h | 6 + arch/mn10300/include/asm/tables.h | 6 + arch/nios2/include/asm/tables.h | 6 + arch/openrisc/include/asm/tables.h | 6 + arch/parisc/include/asm/tables.h | 6 + arch/powerpc/include/asm/tables.h | 6 + arch/s390/include/asm/tables.h | 6 + arch/score/include/asm/tables.h | 6 + arch/sh/include/asm/tables.h | 6 + arch/sparc/include/asm/tables.h | 6 + arch/tile/include/asm/tables.h | 6 + arch/um/include/asm/tables.h | 6 + arch/unicore32/include/asm/tables.h | 6 + arch/x86/include/asm/tables.h | 6 + arch/x86/tools/relocs.c | 3 + arch/xtensa/include/asm/tables.h | 6 + include/asm-generic/tables.h | 70 ++++ include/asm-generic/vmlinux.lds.h | 9 +- include/linux/tables.h | 597 +++++++++++++++++++++++++++++++ scripts/Makefile.build | 4 +- scripts/Makefile.clean | 1 + scripts/Makefile.lib | 12 + tools/include/linux/sections.h | 13 + 42 files changed, 1078 insertions(+), 4 deletions(-) create mode 100644 Documentation/DocBook/linker-tables.tmpl create mode 100644 arch/alpha/include/asm/tables.h create mode 100644 arch/arc/include/asm/tables.h create mode 100644 arch/arm/include/asm/tables.h create mode 100644 arch/arm64/include/asm/tables.h create mode 100644 arch/avr32/include/asm/tables.h create mode 100644 arch/blackfin/include/asm/tables.h create mode 100644 arch/c6x/include/asm/tables.h create mode 100644 arch/cris/include/asm/tables.h create mode 100644 arch/frv/include/asm/tables.h create mode 100644 arch/h8300/include/asm/tables.h create mode 100644 arch/hexagon/include/asm/tables.h create mode 100644 arch/ia64/include/asm/tables.h create mode 100644 arch/m32r/include/asm/tables.h create mode 100644 arch/m68k/include/asm/tables.h create mode 100644 arch/metag/include/asm/tables.h create mode 100644 arch/microblaze/include/asm/tables.h create mode 100644 arch/mips/include/asm/tables.h create mode 100644 arch/mn10300/include/asm/tables.h create mode 100644 arch/nios2/include/asm/tables.h create mode 100644 arch/openrisc/include/asm/tables.h create mode 100644 arch/parisc/include/asm/tables.h create mode 100644 arch/powerpc/include/asm/tables.h create mode 100644 arch/s390/include/asm/tables.h create mode 100644 arch/score/include/asm/tables.h create mode 100644 arch/sh/include/asm/tables.h create mode 100644 arch/sparc/include/asm/tables.h create mode 100644 arch/tile/include/asm/tables.h create mode 100644 arch/um/include/asm/tables.h create mode 100644 arch/unicore32/include/asm/tables.h create mode 100644 arch/x86/include/asm/tables.h create mode 100644 arch/xtensa/include/asm/tables.h create mode 100644 include/asm-generic/tables.h create mode 100644 include/linux/tables.h create mode 100644 tools/include/linux/sections.h
Documentation/DocBook/Makefile +1 -1
@@ -18,7 +18,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ tracepoint.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml iio.xml \ - sections.xml + sections.xml linker-tables.xml include Documentation/DocBook/media/Makefile
Documentation/DocBook/linker-tables.tmpl new file +166 -0
166 lines not on this page · raw message
Documentation/kbuild/makefiles.txt +19 -0
@@ -1089,6 +1089,25 @@ When kbuild executes, the following steps are followed (roughly): In this example, extra-y is used to list object files that shall be built, but shall not be linked as part of built-in.o. + table-y table-m and table- + + To avoid code bit-rot you may wish to avoid using #ifdefs on your + code. Bit-rot is possible if certain features may not be enabled + on certain build environments. The table-y, specifies targets which you + always wish to force compilation on, but wish to only enable linking in + if the feature is enabled, these are features taking advantage of + Linux's linker tables. For details on how to implement a feature using + linker tablesrefer to include/linux/tables.h. Use of table-m is not + yet supported. + + Example: + table-$(CONFIG-FEATURE_FOO) += foo.o + + An alternative to using table-y, is to use extra-y followed by the + respective obj-y: + + extra-y += foo.o + obj-$(CONFIG-FEATURE_FOO) += foo.o --- 6.7 Commands useful for building a boot image
arch/alpha/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ALPHA_TABLES_H +#define _ASM_ALPHA_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_ALPHA_TABLES_H */
arch/arc/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARC_TABLES_H +#define _ASM_ARC_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_ARC_TABLES_H */
arch/arm/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARM_TABLES_H +#define _ASM_ARM_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_ARM_TABLES_H */
arch/arm64/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_ARM64_TABLES_H +#define _ASM_ARM64_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_ARM64_TABLES_H */
arch/avr32/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_AVR32_TABLES_H +#define _ASM_AVR32_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_AVR32_TABLES_H */
arch/blackfin/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_BLACKFIN_TABLES_H +#define _ASM_BLACKFIN_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_BLACKFIN_TABLES_H */
arch/c6x/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_C6X_TABLES_H +#define _ASM_C6X_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_C6X_TABLES_H */
arch/cris/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_CRIS_TABLES_H +#define _ASM_CRIS_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_CRIS_TABLES_H */
arch/frv/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_FRV_TABLES_H +#define _ASM_FRV_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_FRV_TABLES_H */
arch/h8300/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_H8300_TABLES_H +#define _ASM_H8300_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_H8300_TABLES_H */
arch/hexagon/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_HEXAGON_TABLES_H +#define _ASM_HEXAGON_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_HEXAGON_TABLES_H */
arch/ia64/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_IA64_TABLES_H +#define _ASM_IA64_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_IA64_TABLES_H */
arch/m32r/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_M32R_TABLES_H +#define _ASM_M32R_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_M32R_TABLES_H */
arch/m68k/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_M68K_TABLES_H +#define _ASM_M68K_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_M68K_TABLES_H */
arch/metag/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_METAG_TABLES_H +#define _ASM_METAG_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_METAG_TABLES_H */
arch/microblaze/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MICROBLAZE_TABLES_H +#define _ASM_MICROBLAZE_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_MICROBLAZE_TABLES_H */
arch/mips/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MIPS_TABLES_H +#define _ASM_MIPS_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_MIPS_TABLES_H */
arch/mn10300/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_MN10300_TABLES_H +#define _ASM_MN10300_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_MN10300_TABLES_H */
arch/nios2/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_NIOS2_TABLES_H +#define _ASM_NIOS2_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_NIOS2_TABLES_H */
arch/openrisc/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_OPENRISC_TABLES_H +#define _ASM_OPENRISC_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_OPENRISC_TABLES_H */
arch/parisc/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_PARISC_TABLES_H +#define _ASM_PARISC_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_PARISC_TABLES_H */
arch/powerpc/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_POWERPC_TABLES_H +#define _ASM_POWERPC_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_POWERPC_TABLES_H */
arch/s390/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_S390_TABLES_H +#define _ASM_S390_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_S390_TABLES_H */
arch/score/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SCORE_TABLES_H +#define _ASM_SCORE_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_SCORE_TABLES_H */
arch/sh/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SH_TABLES_H +#define _ASM_SH_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_SH_TABLES_H */
arch/sparc/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_SPARC_TABLES_H +#define _ASM_SPARC_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_SPARC_TABLES_H */
arch/tile/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_TILE_TABLES_H +#define _ASM_TILE_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_TILE_TABLES_H */
arch/um/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_UM_TABLES_H +#define _ASM_UM_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_UM_TABLES_H */
arch/unicore32/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_UNICORE32_TABLES_H +#define _ASM_UNICORE32_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_UNICORE32_TABLES_H */
arch/x86/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_X86_TABLES_H +#define _ASM_X86_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_X86_TABLES_H */
arch/x86/tools/relocs.c +3 -0
@@ -1,4 +1,5 @@/* This is included from relocs_32/64.c */ +#include <linux/sections.h> #define ElfW (type) _ElfW(ELF_BITS, type)#define _ElfW (bits, type) __ElfW(bits, type)
@@ -68,6 +69,8 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = {"__end_rodata|" "__initramfs_start|" "(jiffies|jiffies_64)|" + SECTION_TBL_ALL_STR(SECTION_RODATA) "|" + SECTION_TBL_ALL_STR(SECTION_INIT) "|" #if ELF_BITS == 64"__per_cpu_load|" "init_per_cpu__.*|"
arch/xtensa/include/asm/tables.h new file +6 -0
@@ -0,0 +1,6 @@ +#ifndef _ASM_XTENSA_TABLES_H +#define _ASM_XTENSA_TABLES_H + +#include <asm-generic/tables.h> + +#endif /* _ASM_XTENSA_TABLES_H */
include/asm-generic/tables.h new file +70 -0
70 lines not on this page · raw message
include/asm-generic/vmlinux.lds.h +8 -1
@@ -56,6 +56,7 @@#include <linux/export.h> #include <asm/sections.h> +#include <asm/tables.h> /* Align . to a 8 byte boundary equals to maximum function alignment. */ #define ALIGN_FUNCTION () . = ALIGN(8)
@@ -200,6 +201,7 @@/* .data section */ #define DATA_DATA \ *(SECTION_DATA) \ + *(SORT(SECTION_TBL_ALL(SECTION_DATA))) \ *(SECTION_REF_DATA) \ *(.data..shared_aligned)/* percpu related */ \MEM_KEEP (init.data) \
@@ -265,7 +267,9 @@ . = ALIGN((align)); \ SECTION_RODATA : AT(ADDR(SECTION_RODATA) - LOAD_OFFSET) { \ VMLINUX_SYMBOL(__start_rodata) = .; \ - *(SECTION_RODATA ) *(SECTION_ALL (SECTION_RODATA )) \ + *(SECTION_RODATA ) \ + *(SORT (SECTION_TBL_ALL (SECTION_RODATA ))) \ + *(SECTION_ALL (SECTION_RODATA )) \RO_AFTER_INIT_DATA /* Read only after init */ \ *(__vermagic)/* Kernel version magic */ \ . = ALIGN(8); \
@@ -434,6 +438,7 @@#define TEXT_TEXT \ ALIGN_FUNCTION(); \ *(.text.hot SECTION_TEXT .text.fixup .text.unlikely) \ + *(SORT(SECTION_TBL_ALL(SECTION_TEXT))) \ *(SECTION_REF) \ MEM_KEEP(init.text) \ MEM_KEEP(exit.text) \
@@ -529,6 +534,7 @@/* init and exit section handling */ #define INIT_DATA \ *(SECTION_INIT_DATA) \ + *(SORT(SECTION_TBL_ALL(SECTION_INIT_DATA))) \ MEM_DISCARD(init.data) \ KERNEL_CTORS() \ MCOUNT_REC() \
@@ -551,6 +557,7 @@#define INIT_TEXT \ *(SECTION_INIT) \ + *(SORT(SECTION_TBL_ALL(SECTION_INIT))) \ *(.text.startup) \ MEM_DISCARD(init.text)
include/linux/tables.h new file +597 -0
597 lines not on this page · raw message
scripts/Makefile.build +2 -2
@@ -91,7 +91,7 @@ modorder-target := $(obj)/modules.order # We keep a list of all modules in $(MODVERDIR) -__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \ +__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y) $(table-y)) \ $(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \ $(subdir-ym) $(always) @:
@@ -326,7 +326,7 @@ $(obj)/%.o: $(src)/%.S $(objtool_obj) FORCE $(call if_changed_rule,as_o_S) targets += $(real-objs-y) $(real-objs-m) $(lib-y) -targets += $(extra-y) $(MAKECMDGOALS) $(always) +targets += $(extra-y) $(table-y) $(MAKECMDGOALS) $(always) # Linker scripts preprocessor (.lds.S -> .lds) # ---------------------------------------------------------------------------
scripts/Makefile.clean +1 -0
@@ -36,6 +36,7 @@ subdir-ymn := $(addprefix $(obj)/,$(subdir-ymn)) # directory __clean-files := $(extra-y) $(extra-m) $(extra-) \ + $(table-y) $(table-m) $(table-) \ $(always) $(targets) $(clean-files) \ $(host-progs) \ $(hostprogs-y) $(hostprogs-m) $(hostprogs-) \
scripts/Makefile.lib +12 -0
@@ -12,6 +12,16 @@ export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS) $(subdir-ccflags-y) # Figure out what we need to build from the various variables # =========================================================================== +# Linker tables objects always wish to be built to avoid bit-rot in +# code, but only linked in *iff* they were enabled. We accomplish this +# using pegging linker table objects into extra-y, which forces +# compilation and then using the respective table-y and table-m as +# as hints for things we do want enabled. Objects which we want to +# avoid linking in will be in table-, not table-y and table-m. +extra-y += $(table-) +obj-m += $(table-m) +obj-y += $(table-y) + # When an object is listed to be built compiled-in and modular, # only build the compiled-in version
@@ -72,6 +82,8 @@ real-objs-m := $(foreach m, $(obj-m), $(if $(strip $($(m:.o=-objs)) $($(m:.o=-y) # Add subdir path extra-y := $(addprefix $(obj)/,$(extra-y)) +table-y := $(addprefix $(obj)/,$(table-y)) +table-m := $(addprefix $(obj)/,$(table-m)) always := $(addprefix $(obj)/,$(always)) targets := $(addprefix $(obj)/,$(targets)) modorder := $(addprefix $(obj)/,$(modorder))
tools/include/linux/sections.h new file +13 -0
@@ -0,0 +1,13 @@ +#ifndef _TOOLS_LINUX_SECTIONS_H_ + +/* Mostly a copy of what we need only */ + +#define SECTION_INIT .init.text +#define SECTION_RODATA .rodata + +#define ___SECTION_TBL_STR (section, name) \ + #section ".tbl." #name +#define SECTION_TBL_ALL_STR (section) \ + ___SECTION_TBL_STR(section, *) + +#endif /* _TOOLS_LINUX_SECTIONS_H_ */
Signature · 1 line
2.8.4
Masami Hiramatsu
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 27 lines · On Fri, 22 Jul 2016 14:24:41 -0700 "Luis R. Rodriguez" <[email protected]>…
include/linux/tables.h new file +27
-0+/** +* LINKTABLE_RUN_ALL - iterate and run through all entries on a linker table +* +* @tbl: linker table +* @func: structure name for the function name we want to call. +* @args...: arguments to pass to func +* +* Example usage: +* +* LINKTABLE_RUN_ALL(frobnicator_fns, some_run,); +*/ +#define LINKTABLE_RUN_ALL(tbl, func, args...) \ +do { \ + size_t i; \ + for (i = 0; i < LINUX_SECTION_SIZE(tbl); i++) \ + (tbl[i]).func (args); \ +} while (0); + +/** +* LINKTABLE_RUN_ERR - run each linker table entry func and return error if any +* +* @tbl: linker table +* @func: structure name for the function name we want to call. +* @args...: arguments to pass to func +* +* Example usage: +*
include/linux/tables.h line 593
Quoted 10 lines
include/linux/tables.h new file +10
-0+* unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns, some_run,); +*/ +#define LINKTABLE_RUN_ERR(tbl, func, args...) \ +({ \ + size_t i; \ + int err = 0; \ + for (i = 0; !err && i < LINUX_SECTION_SIZE(tbl); i++) \ + err = (tbl[i]).func (args); \ + err; \ +})
These iteration APIs are a bit dangerous, at least for these APIs we'd better change name like as FUNCTABLE_RUN etc. because LINKTABLE can contain not only function address but also some data (or address of data).
Thank you,
Signature · 1 line
Masami Hiramatsu <[email protected]>
Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 36 lines · Masami Hiramatsu
Quoted 33 lines · On Fri, 22 Jul 2016 14:24:41 -0700 "Luis R. Rodriguez" <[email protected]>…
include/linux/tables.h new file +33
-0+/** +* LINKTABLE_RUN_ALL - iterate and run through all entries on a linker table +* +* @tbl: linker table +* @func: structure name for the function name we want to call. +* @args...: arguments to pass to func +* +* Example usage: +* +* LINKTABLE_RUN_ALL(frobnicator_fns, some_run,); +*/ +#define LINKTABLE_RUN_ALL(tbl, func, args...) \ +do { \ + size_t i; \ + for (i = 0; i < LINUX_SECTION_SIZE(tbl); i++) \ + (tbl[i]).func (args); \ +} while (0); + +/** +* LINKTABLE_RUN_ERR - run each linker table entry func and return error if any +* +* @tbl: linker table +* @func: structure name for the function name we want to call. +* @args...: arguments to pass to func +* +* Example usage: +* +* unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns, some_run,); +*/ +#define LINKTABLE_RUN_ERR(tbl, func, args...) \ +({ \ + size_t i; \ + int err = 0; \
Quoted 8 lines
include/linux/tables.h line 593
Quoted 4 lines
include/linux/tables.h new file +4
-0+for (i =0 ; !err && i <LINUX_SECTION_SIZE (tbl); i++) \ + err = (tbl[i]).func (args); \ + err; \ +})These iteration APIs are a bit dangerous, at least for these APIs we'd better change name like as
FUNCTABLE_RUNetc. because LINKTABLE can contain not only function address but also some data (or address of data).
Sure will do, thanks for the review.
Luis
H. Peter Anvin
reviewerRe: [RFC v3 07/13] tables.h: add linker table support
[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],jko!
sina@suse
.cz,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
Message-ID: <[email protected]>
Quoted 46 lines · Luis R. Rodriguez
Quoted 5 lines · Masami Hiramatsu
Quoted 2 lines · On Fri, 22 Jul 2016 14:24:41 -0700 "Luis R. Rodriguez" <[email protected]>…
+/**
+ *LINKTABLE_RUN_ALL- iterate and run through all entries on alinker table
Quoted 10 lines
Quoted 10 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ *LINKTABLE_RUN_ALL(frobnicator_fns, some_run,);
+ */
+#defineLINKTABLE_RUN_ALL(tbl, func, args...)\Quoted 8 lines
include/linux/tables.h
Quoted 8 lines
include/linux/tables.h new file +8
-0+do { \ +size_t i; \ +for (i =0 ; i <LINUX_SECTION_SIZE (tbl); i++) \ + (tbl[i]).func (args); \ +}while (0 ); + +/** +* LINKTABLE_RUN_ERR - run each linker table entry func and return error if any
Quoted 8 lines
Quoted 8 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ * unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns,
some_run,);Quoted 11 lines
include/linux/tables.h line 593
Quoted 9 lines
+ */
include/linux/tables.h new file +8
-0+#define LINKTABLE_RUN_ERR(tbl, func, args...) \ +({ \ + size_t i; \ + int err = 0; \ + for (i = 0; !err && i < LINUX_SECTION_SIZE(tbl); i++) \ + err = (tbl[i]).func (args); \ + err; \ +})These iteration APIs are a bit dangerous, at least for these APIs
Quoted 8 lines
we'd better change
Quoted 1 line
name like as
FUNCTABLE_RUNetc. because LINKTABLE can contain notonly function address
Quoted 1 line
but also some data (or address of data).
Sure will do, thanks for the review.
Luis
I don't know if they are dangerous. Keep in mind C type checking is still present.
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
H. Peter Anvin
reviewerRe: [RFC v3 07/13] tables.h: add linker table support
In reply to Luis R. Rodriguez[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],jko!
sina@suse
.cz,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
Message-ID: <[email protected]>
Quoted 46 lines · Luis R. Rodriguez
Quoted 5 lines · Masami Hiramatsu
Quoted 2 lines · On Fri, 22 Jul 2016 14:24:41 -0700 "Luis R. Rodriguez" <[email protected]>…
+/**
+ *LINKTABLE_RUN_ALL- iterate and run through all entries on alinker table
Quoted 10 lines
Quoted 10 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ *LINKTABLE_RUN_ALL(frobnicator_fns, some_run,);
+ */
+#defineLINKTABLE_RUN_ALL(tbl, func, args...)\Quoted 8 lines
include/linux/tables.h
Quoted 8 lines
include/linux/tables.h new file +8
-0+do { \ +size_t i; \ +for (i =0 ; i <LINUX_SECTION_SIZE (tbl); i++) \ + (tbl[i]).func (args); \ +}while (0 ); + +/** +* LINKTABLE_RUN_ERR - run each linker table entry func and return error if any
Quoted 8 lines
Quoted 8 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ * unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns,
some_run,);Quoted 11 lines
include/linux/tables.h line 593
Quoted 9 lines
+ */
include/linux/tables.h new file +8
-0+#define LINKTABLE_RUN_ERR(tbl, func, args...) \ +({ \ + size_t i; \ + int err = 0; \ + for (i = 0; !err && i < LINUX_SECTION_SIZE(tbl); i++) \ + err = (tbl[i]).func (args); \ + err; \ +})These iteration APIs are a bit dangerous, at least for these APIs
Quoted 8 lines
we'd better change
Quoted 1 line
name like as
FUNCTABLE_RUNetc. because LINKTABLE can contain notonly function address
Quoted 1 line
but also some data (or address of data).
Sure will do, thanks for the review.
Luis
I don't know if they are dangerous. Keep in mind C type checking is still present.
Signature · 6 lines
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting. _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel
H. Peter Anvin
reviewerRe: [RFC v3 07/13] tables.h: add linker table support
In reply to Luis R. Rodriguez[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],paul.gortma
[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],jko!
sina@suse
.cz,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
Message-ID: <[email protected]>
Quoted 46 lines · Luis R. Rodriguez
Quoted 5 lines · Masami Hiramatsu
Quoted 2 lines · On Fri, 22 Jul 2016 14:24:41 -0700 "Luis R. Rodriguez" <[email protected]>…
+/**
+ *LINKTABLE_RUN_ALL- iterate and run through all entries on alinker table
Quoted 10 lines
Quoted 10 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ *LINKTABLE_RUN_ALL(frobnicator_fns, some_run,);
+ */
+#defineLINKTABLE_RUN_ALL(tbl, func, args...)\Quoted 8 lines
include/linux/tables.h
Quoted 8 lines
include/linux/tables.h new file +8
-0+do { \ +size_t i; \ +for (i =0 ; i <LINUX_SECTION_SIZE (tbl); i++) \ + (tbl[i]).func (args); \ +}while (0 ); + +/** +* LINKTABLE_RUN_ERR - run each linker table entry func and return error if any
Quoted 8 lines
Quoted 8 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ * unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns,
some_run,);Quoted 11 lines
include/linux/tables.h line 593
Quoted 9 lines
+ */
include/linux/tables.h new file +8
-0+#define LINKTABLE_RUN_ERR(tbl, func, args...) \ +({ \ + size_t i; \ + int err = 0; \ + for (i = 0; !err && i < LINUX_SECTION_SIZE(tbl); i++) \ + err = (tbl[i]).func (args); \ + err; \ +})These iteration APIs are a bit dangerous, at least for these APIs
Quoted 8 lines
we'd better change
Quoted 1 line
name like as
FUNCTABLE_RUNetc. because LINKTABLE can contain notonly function address
Quoted 1 line
but also some data (or address of data).
Sure will do, thanks for the review.
Luis
I don't know if they are dangerous. Keep in mind C type checking is still present.
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
H. Peter Anvin
reviewerRe: [RFC v3 07/13] tables.h: add linker table support
In reply to Luis R. Rodriguez[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],paul.gortma
[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],jko!
sina@suse
.cz,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
Message-ID: <[email protected]>
Quoted 46 lines · Luis R. Rodriguez
Quoted 5 lines · Masami Hiramatsu
Quoted 2 lines · On Fri, 22 Jul 2016 14:24:41 -0700 "Luis R. Rodriguez" <[email protected]>…
+/**
+ *LINKTABLE_RUN_ALL- iterate and run through all entries on alinker table
Quoted 10 lines
Quoted 10 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ *LINKTABLE_RUN_ALL(frobnicator_fns, some_run,);
+ */
+#defineLINKTABLE_RUN_ALL(tbl, func, args...)\Quoted 8 lines
include/linux/tables.h
Quoted 8 lines
include/linux/tables.h new file +8
-0+do { \ +size_t i; \ +for (i =0 ; i <LINUX_SECTION_SIZE (tbl); i++) \ + (tbl[i]).func (args); \ +}while (0 ); + +/** +* LINKTABLE_RUN_ERR - run each linker table entry func and return error if any
Quoted 8 lines
Quoted 8 lines
+ *
+ * @tbl: linker table
+ * @func: structure name for the function name we want to call.
+ * @args...: arguments to pass to func
+ *
+ * Example usage:
+ *
+ * unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns,
some_run,);Quoted 11 lines
include/linux/tables.h line 593
Quoted 9 lines
+ */
include/linux/tables.h new file +8
-0+#define LINKTABLE_RUN_ERR(tbl, func, args...) \ +({ \ + size_t i; \ + int err = 0; \ + for (i = 0; !err && i < LINUX_SECTION_SIZE(tbl); i++) \ + err = (tbl[i]).func (args); \ + err; \ +})These iteration APIs are a bit dangerous, at least for these APIs
Quoted 8 lines
we'd better change
Quoted 1 line
name like as
FUNCTABLE_RUNetc. because LINKTABLE can contain notonly function address
Quoted 1 line
but also some data (or address of data).
Sure will do, thanks for the review.
Luis
I don't know if they are dangerous. Keep in mind C type checking is still present.
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Borislav Petkov
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
In reply to Luis R. RodriguezQuoted 8 lines · Luis R. Rodriguez
A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker table solution so that a new linker table can be implemented by changing C code only. The Linux linker table was originally based on Michael Brown's iPXE's linker table solution but has been significantly modified to fit Linux's use in its integration.
...
Quoted 13 lines
include/asm-generic/tables.h new file +7
-0@@ -0,0 +1,70 @@ +#ifndef _ASM_GENERIC_TABLES_H_ +#define _ASM_GENERIC_TABLES_H_ +/* +* Linux linker tables +* +* Copyright (C) 2016 Luis R. Rodriguez <[email protected]> +*
include/asm-generic/tables.h line 17
Quoted 10 lines
include/asm-generic/tables.h new file +10
-0+* This program is free software; you can redistribute it and/or modify it +* under the terms of copyleft-next (version 0.3.1 or later) as published +* at http://copyleft-next.org/. +*/ + +#ifdef __KERNEL__ +# include <asm/sections.h> +#endif /* __KERNEL__ */ + +#define SECTION_TYPE_TABLES tbl
What is that for? Section type? Do we have more types or is it useless and can go?
include/asm-generic/tables.h line 28
Quoted 11 lines
include/asm-generic/tables.h new file +11
-0+ +#define SECTION_TBL (section, name, level) \ + SECTION_TYPE(section, SECTION_TYPE_TABLES, name, level) + +#define SECTION_TBL_ALL (section) \ + SECTION_TYPE_ALL(section,SECTION_TYPE_TABLES) + +#ifndef section_tbl +# define section_tbl (section, name, level, flags) \ + section_type(section, SECTION_TYPE_TABLES, name, \ + level, flags)
That section_type macro is actually saying the following code should be in it. Can we make its name have a verb, i.e., something like "set_section" to make it more clear?
Also, that type SECTION_TYPE_TABLES looks redundant to me but it might start making more sense after I've gone through the rest of the series...
include/asm-generic/tables.h line 38
Quoted 10 lines
include/asm-generic/tables.h new file +10
-0+#endif + +#ifndef section_tbl_any +# define section_tbl_any (section, name, flags) \ + section_type(section, SECTION_TYPE_TABLES, name, \ + SECTION_ORDER_ANY, flags) +#endif + +#ifndef section_tbl_asmtype +# define section_tbl_asmtype (section, name, level, flags, asmtype) \
And here's the confusion: there's "asmtype" but there's also SECTION_TYPE_TABLES.
That asmtype is the *actual* section type in gas speak, i.e., @progbits, @note, etc.
Now *that* should be your type. The SECTION_TYPE_TABLES should be called something else or completely gone.
Quoted 18 lines
include/asm-generic/tables.h new file +18
-0+section_type_asmtype (section,SECTION_TYPE_TABLES , name, \ + level, flags, asmtype) +#endif + +#ifndef push_section_tbl +# define push_section_tbl (section, name, level, flags) \ + push_section_type(section, SECTION_TYPE_TABLES, name, \ + level, flags) +#endif + +#ifndef push_section_tbl_any +# define push_section_tbl_any (section, name, flags) \ + push_section_type(section, SECTION_TYPE_TABLES, name, \ + SECTION_ORDER_ANY, flags) +#endif + +#if defined(__ASSEMBLER__) || defined(__ASSEMBLY__) +
include/asm-generic/tables.h line 66
Quoted 10 lines
include/asm-generic/tables.h new file +10
-0+# ifndef DECLARE_SECTION_TBL +# define DECLARE_SECTION_TBL (section, name) \ + push_section_tbl(section, name,,) ; \ + .globl name ; \ +name: ; \ + .popsection \ + \ + push_section_tbl(section, name, ~,) ; \ + .popsection +# endif
#endif /* DECLARE_SECTION_TBL */
Btw, what does that macro do? I don't see it used anywhere.
Quoted 4 lines
include/asm-generic/tables.h new file +4
-0+ +#endif /* defined(__ASSEMBLER__) || defined(__ASSEMBLY__) */ + +#endif /* _ASM_GENERIC_TABLES_H_ */
...
Quoted 19 lines
include/linux/tables.h new file +13
-0@@ -0,0 +1,597 @@ +#ifndef _LINUX_LINKER_TABLES_H +#define _LINUX_LINKER_TABLES_H +/* +* Linux linker tables +* +* Copyright (C) 2016 Luis R. Rodriguez <[email protected]> +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of copyleft-next (version 0.3.1 or later) as published +* at http://copyleft-next.org/. +*/ +#include <linux/sections.h> +#ifdef __KERNEL__
include/linux/tables.h line 23
Quoted 10 lines
include/linux/tables.h new file +10
-0+# include <asm/tables.h> +#endif /* __KERNEL__ */ + +#ifndef __ASSEMBLY__ + +/** +* DOC: Introduction +* +* A linker table is a data structure that is stitched together from items +* in multiple object files. Linux has historically implicitly used linker
s/historically//
"for ages" already says "historically" :-)
include/linux/tables.h line 25
Quoted 2 lines
include/linux/tables.h new file +2
-0+* tables for ages, however they were all built in an adhoc manner which +* requires linker script modifications, per architecture. This linker table
s/,//
include/linux/tables.h line 31
Quoted 6 lines
include/linux/tables.h new file +6
-0+* solution provides a general linker table facility so that a new linker table +* can be implemented by changing C code only. +* +* Linker tables help you simplify init sequences by using ELF sections, linker +* build time selective sorting (disabled options get ignored), and can +* optionally also be used to help you avoid code bit-rot due to #ifdery
"ifdeffery"
include/linux/tables.h line 32
Quoted 1 line
include/linux/tables.h new file +1
-0+* collateral.
... and I don't understand what "ifdeffery collateral" means.
include/linux/tables.h line 40
Quoted 8 lines
include/linux/tables.h new file +8
-0+*/ + +/** +* DOC: Linker table provenance and userspace testing +* +* The Linux implementation of linker tables is derivative of iPXE linker +* table's solution (iPXE commit 67a10ef000cb7 [0]). To see how this code +* evolved or to extend and test and use this code in userspace refer to the
"... to extend, test and use... "
include/linux/tables.h line 43
Quoted 3 lines
include/linux/tables.h new file +3
-0+* userspace linker-table tree [1]. This repository can be used for ease of +* testing of extensions and sampling of changes prior to inclusion into Linux, +* it is intended to be kept up to date to match Linux's solution. Contrary to
Keeping different pieces of code in sync is always a PITA.
Can we automatically extract the kernel linker tables into a standalone userspace pile of C code for experimentation? I.e., something like
make linker_tables_app
or so...
include/linux/tables.h line 44
Quoted 1 line
include/linux/tables.h new file +1
-0+* iPXE's solution, which strives to force compilation of everything using
s/,//
Quoted 8 lines
include/linux/tables.h new file +8
-0+* linker tables, Linux's solution allows for developers to be selective over +* where one wishes to force compilation, this then is just an optional feature +* for the Linux linker table solution. +* +* [0] git://git.ipxe.org/ipxe.git +* +* [1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/ +*/
include/linux/tables.h line 62
Quoted 10 lines
include/linux/tables.h new file +10
-0+ +/** +* DOC: The code bit-rot problem +* +* Overuse of C #ifdefs can be problematic for certain types of code. Linux +* provides a rich array of features, but all these features take up valuable +* space in a kernel image. The traditional solution to this problem has been +* for each feature to have its own Kconfig entry and for the respective code +* to be wrapped around #ifdefs, allowing the feature to be compiled in only +* if desired.
"... if enabled in Kconfig."
include/linux/tables.h line 65
Quoted 3 lines
include/linux/tables.h new file +3
-0+* +* The problem with this is that over time it becomes very difficult and time +* consuming to compile, let alone test, all possible versions of Linux. Code
"all possible Kconfig configurations."
include/linux/tables.h line 74
Quoted 9 lines
include/linux/tables.h new file +9
-0+* that is not typically used tends to suffer from bit-rot over time. It can +* become difficult to predict which combinations of compile-time options will +* result in code that can compile and link correctly. +*/ + +/** +* DOC: Avoiding the code bit-rot problem when desirable +* +* To solve the code bit-rot problem linker tables can be used on Linux, it
"One way to solve this ..." "... on Linux. It enables..."
include/linux/tables.h line 77
Quoted 3 lines
include/linux/tables.h new file +3
-0+* enables you to always force compiling of select features that one wishes to +* avoid bit-rot while still enabling you to disable linking feature code into +* the final kernel image if the features have been disabled via Kconfig.
So this sounds to me like the main reason for linker tables is solving the bitrot problem. And I don't think that is the main reason for them, is it?
Because we can address the bitrot issue by simply building randconfigs, without even touching the kernel. So why do we need those linker tables?
include/linux/tables.h line 89
Quoted 12 lines
include/linux/tables.h new file +12
-0+* Linux's linker tables allows for developers to be selective over where one +* wishes to take advantage of the optional feature of forcing compilation and +* only linking in enabled features. +* +* To use linker tables and to optionally take advantage of avoiding code +* bit-rot, feature code should be implemented in separate C files, and should +* be designed to always be compiled -- they should not be guarded with a C +* code #ifdef CONFIG_FOO statements, consideration must also be taken for +* sub-features which depend on the main CONFIG_FOO option, as they will be +* disabled if they depend on CONFIG_FOO and therefore not compiled. To force +* compilation and only link when features are needed a new optional target +* table-y can be used on Makefiles, documented below.
Ok, this is more like it. Linker tables actually diminish the Kconfig complexity. I'd lead with that.
include/linux/tables.h
Quoted 3 lines
include/linux/tables.h new file +3
-0+* +* Currently only built-in features are supported, modular support is not +* yet supported,
"... modular support ... supported ... " Avoid tautology pls.
Quoted 4 lines
however you can make use of sub-features for modules
+ * if they are independent and can simply be linked into modules.
+ */include/linux/tables.h new file +1
-0+
include/linux/tables.h line 105
Quoted 10 lines
include/linux/tables.h new file +10
-0+/** +* DOC: Using target table-y and table-n +* +* Let's assume we want to always force compilation of feature FOO in the +* kernel but avoid linking it. When you enable the FOO feature via Kconfig +* you'd end up with: +* +* #define CONFIG_FOO 1 +* +* You typically would then just use this on your Makefile to selectively
s/on/in/
Quoted 18 lines
+ * compile and link the feature:
+ *
+ * obj-$(CONFIG_FOO) += foo.o
+ *
+ * You could instead optionally use the new linker table object:
+ *
+ * table-$(CONFIG_FOO) += foo.o
+ *
+ * Alternatively, this would be the equivalent of listing:
+ *
+ * extra += foo.o
+ * obj-$(CONFIG_FOO) += foo.o
+ *
+ * Both are mechanisms which can be used to take advantage of forcing
+ * compilation with linker tables, however making use of table-$(CONFIG_FOO)
+ * is encouraged as it helps with annotating linker tables clearly where
+ * compilation is forced.
+ */
include/linux/tables.h line 130
Quoted 7 lines
include/linux/tables.h new file +7
-0+ +/** +* DOC: Opting out of forcing compilation +* +* If you want to opt-out of forcing compilation you would use the typical +* obj-$(CONFIG_FOO) += foo.o and foo.o will only be compiled and linked +* in when enabled. Using both table-$(CONFIG_FOO) and obj-($CONFIG_FOO)
"... when CONFIG_FOO is enabled."
Quoted 3 lines
+ * will result with the feature on your binary only if you've enabled
+ *CONFIG_FOO, however using table-$(CONFIG_FOO) will always force compilation,
+ * this is why avoiding code bit-rot is an optional fature for Linux linker
"fature" - please run it through spellchecker.
Btw, I'm afraid this "table-$(CONFIG" thing might be misused by people wanting their stuff to be compile-tested and we'd end up practically building an allyesconfig each time.
So how can I disable those table-* things from even getting built? Avoid using table-y?
But then everything declared table-y will be built unconditionally. I don't think I like that. :-\
include/linux/tables.h line 140
Quoted 7 lines
+ * tables.
+ */include/linux/tables.h new file +5
-0+ +/** +* DOC: How linker tables simplify inits +* +* Traditionally, we would implement features in C code as follows:
Ok, so *this* is your main reason for linker tables - not fixing the bit-rot problem. The text on the bit-rot problem should come second and be the byproduct of linker tables.
Also, this section here should be the opening section in the document explaining linker tables. I'd like to read about what it is first, then read what else they're good for.
Quoted 13 lines
+ *
+ *foo_init();
+ *
+ * You'd then have afoo.hwhich would have:
+ *
+ * #ifdefCONFIG_FOO
+ * #else
+ * static inline void foo(void) { }
+ * #endif
+ *
+ * With linker tables this is no longer necessary as your init routines would
+ * be implicit, you'd instead call:
+ *
Quoted 8 lines
+ *
call_init_fns();
+ *
+ *call_init_fns()would call all functions present in your init table and if
+ * and only if foo.o gets linked in, then its initialisation function will be
+ * called, whether you use obj-$(CONFIG_FOO) or table-$(CONFIG_FOO).
+ *
+ * The linker script takes care of assembling the tables for us. All of our
+ * table sections have names of the format SECTION_NAME*.tbl.NAME.N. Here
The fact that you actually say "tbl" here shows again SECTION_TYPE_TABLES is redundant.
Quoted 2 lines
+ *
SECTION_NAMEis one of the standard sections ininclude/linux/sections.h,
+ * and NAME designates the specific use case for the linker table, the table.
s/, the table//
<--- new paragraph starts here
Quoted 1 line
+ * N is a digit decimal number used to impose an "order level" upon the tables
digit *and* decimal number? :-)
Quoted 1 line
+ * if required. NN= (empty string) is reserved for the symbol indicating "table
NN= or N= ?
Quoted 4 lines
+ * start", and N=~ is reserved for the symbol indicating "table end". In order
+ * for thecall_init_fns()to work behind the scenes the custom linker script
+ * would need to define the beginning of the table, the end of the table, and
+ * in between it should useSORT()to give order-level effect. Now, typically
So basically N makes the section names sortable...
Quoted 1 line
+ * such type of requirements would require custom linker script modifications
Duude, you're killing me: "such type of requirements would require"
Quoted 1 line
+ * but Linux's linker tables builds on top of already existing standard Linux
build
Quoted 5 lines
+ * ELF sections, each with different purposes. This lets you build and add
+ * new tables without needing custom linker script modifications. This is
+ * also done to support all architectures. All that is needed then is to
+ * ensure a respective common linker table entry is added to the shared
+ *include/asm-generic/vmlinux.lds.h.
<-- new paragraph starts here:
Quoted 8 lines
There should be a respective:
+ *
+ * *(SORT(SECTION_TBL_ALL(SECTION_NAME)))
+ *
+ * entry for each type of supported section there. If yourSECTION_NAME
+ * is not yet supported, consider adding support for it.
+ *
+ * The order-level is really only a helper, if only one order level is
order-level??
What that?
Quoted 45 lines
+ * used, the next contributing factor to order is the order of the code
+ * in the C file, and the order of the objects in theMakefile. Using
+ * an order level then should not really be needed in most cases, its
+ * use however enables to compartamentalize code into tables where ordering
+ * through C file or through theMakefilewould otherwise be very difficult
+ * or if one wanted to enable very specific initialization semantics.
+ *
+ * As an example, suppose that we want to create a "frobnicator"
+ * feature framework, and allow for several independent modules to
+ * provide frobnicating services. Then we would create afrob.h
+ * header file containing e.g.
+ *
+ * struct frobnicator {
+ * const char *name;
+ * void (*frob) (void);
+ * };
+ *
+ *DECLARE_LINKTABLE(struct frobnicator, frobnicator_fns);
+ *
+ * Any module providing frobnicating services would look something
+ * like
+ *
+ * #include "frob.h"
+ * static voidmy_frob(void){
+ * ... Do my frobnicating
+ * }
+ *LINKTABLE_INIT_DATA(frobnicator_fns, all)my_frobnicator= {
+ * .name = "my_frob",
+ * .frob =my_frob,
+ * };
+ *
+ * The central frobnicator code (frob.c) would use the frobnicating
+ * modules as follows
+ *
+ * #include "frob.h"
+ *
+ * voidfrob_all(void){
+ * struct frob *frob;
+ *
+ *LINKTABLE_FOR_EACH(frob, frobnicator_fns){
+ *pr_info("Calling frobnicator \"%s\"\n", frob->name);
+ *frob->frob();
+ * }
+ * }
+ */
include/linux/tables.h line 234
Quoted 6 lines
include/linux/tables.h new file +6
-0+ +/** +* DOC: Linker table helpers +* +* These are helpers for linker tables. +*/
I'm assuming those are all needed and we're not adding them just for completeness...
Otherwise, they'll bit-rot. :-))))
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 30 lines · Borislav Petkov
Quoted 8 lines · Luis R. Rodriguez
A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker table solution so that a new linker table can be implemented by changing C code only. The Linux linker table was originally based on Michael Brown's iPXE's linker table solution but has been significantly modified to fit Linux's use in its integration.
...
Quoted 18 lines
include/asm-generic/tables.h new file +12
-0@@ -0,0 +1,70 @@ +#ifndef _ASM_GENERIC_TABLES_H_ +#define _ASM_GENERIC_TABLES_H_ +/* +* Linux linker tables +* +* Copyright (C) 2016 Luis R. Rodriguez <[email protected]> +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of copyleft-next (version 0.3.1 or later) as published +* at http://copyleft-next.org/. +*/ +
Quoted 8 lines
include/asm-generic/tables.h line 17
Quoted 5 lines
include/asm-generic/tables.h new file +5
-0+#ifdef __KERNEL__ +# include <asm/sections.h> +#endif /* __KERNEL__ */ + +#define SECTION_TYPE_TABLES tblWhat is that for? Section type? Do we have more types or is it useless and can go?
We have two types, tables and ranges. But I'll drop that.
Quoted 7 lines
Quoted 7 lines
include/asm-generic/tables.h new file +7
-0+ +#define SECTION_TBL (section, name, level) \ + SECTION_TYPE(section, SECTION_TYPE_TABLES, name, level) + +#define SECTION_TBL_ALL (section) \ + SECTION_TYPE_ALL(section,SECTION_TYPE_TABLES) +
Quoted 8 lines
include/asm-generic/tables.h line 28
Quoted 4 lines
include/asm-generic/tables.h new file +4
-0+#ifndef section_tbl +# define section_tbl (section, name, level, flags) \ + section_type(section, SECTION_TYPE_TABLES, name, \ + level, flags)That
section_typemacro is actually saying the following code should be in it. Can we make its name have a verb, i.e., something like "set_section" to make it more clear?
Sure, thanks changed.
Quoted 3 lines
Also, that type
SECTION_TYPE_TABLESlooks redundant to me but it might start making more sense after I've gone through the rest of the series...
I've dropped the type thing.
Quoted 14 lines
include/asm-generic/tables.h line 38
Quoted 10 lines
include/asm-generic/tables.h new file +10
-0+#endif + +#ifndef section_tbl_any +# define section_tbl_any (section, name, flags) \ + section_type(section, SECTION_TYPE_TABLES, name, \ + SECTION_ORDER_ANY, flags) +#endif + +#ifndef section_tbl_asmtype +# define section_tbl_asmtype (section, name, level, flags, asmtype) \And here's the confusion: there's "asmtype" but there's also
SECTION_TYPE_TABLES.
Quoted 5 lines
That asmtype is the *actual* section type in gas speak, i.e., @progbits, @note, etc.
Now *that* should be your type. The
SECTION_TYPE_TABLESshould be called something else or completely gone.
Right, OK dropped and only kept type for this.
Quoted 31 lines
Quoted 18 lines
include/asm-generic/tables.h new file +18
-0+section_type_asmtype (section,SECTION_TYPE_TABLES , name, \ + level, flags, asmtype) +#endif + +#ifndef push_section_tbl +# define push_section_tbl (section, name, level, flags) \ + push_section_type(section, SECTION_TYPE_TABLES, name, \ + level, flags) +#endif + +#ifndef push_section_tbl_any +# define push_section_tbl_any (section, name, flags) \ + push_section_type(section, SECTION_TYPE_TABLES, name, \ + SECTION_ORDER_ANY, flags) +#endif + +#if defined(__ASSEMBLER__) || defined(__ASSEMBLY__) +include/asm-generic/tables.h line 66
Quoted 10 lines
include/asm-generic/tables.h new file +10
-0+# ifndef DECLARE_SECTION_TBL +# define DECLARE_SECTION_TBL (section, name) \ + push_section_tbl(section, name,,) ; \ + .globl name ; \ +name: ; \ + .popsection \ + \ + push_section_tbl(section, name, ~,) ; \ + .popsection +# endif #endif /*
DECLARE_SECTION_TBL*/
Quoted 1 line
Btw, what does that macro do? I don't see it used anywhere.
It can be used in asm code to do actually what DEFINE_LINKTABLE() does but now that I think about it this should then match the name and we'd need one per standard section, as we have for linker table in C code. I've demo'd this use in the userspace mockup git tree but with section ranges. In the meantime I've dropped these macros from this series for now. When we need them we can add them.
Quoted 10 lines
include/asm-generic/tables.h line 69
Quoted 3 lines
include/asm-generic/tables.h new file +3
-0+* userspace linker-table tree [1]. This repository can be used for ease of +* testing of extensions and sampling of changes prior to inclusion into Linux, +* it is intended to be kept up to date to match Linux's solution. Contrary to Keeping different pieces of code in sync is always a PITA.
Can we automatically extract the kernel linker tables into a standalone userspace pile of C code for experimentation? I.e., something like
make
linker_tables_app
Sure. Will shoot for that.
Quoted 7 lines
include/asm-generic/tables.h
Quoted 3 lines
include/asm-generic/tables.h new file +3
-0+* enables you to always force compiling of select features that one wishes to +* avoid bit-rot while still enabling you to disable linking feature code into +* the final kernel image if the features have been disabled via Kconfig. So this sounds to me like the main reason for linker tables is solving the bitrot problem. And I don't think that is the main reason for them, is it?
Not for us, it just one added benefit that's possible from it.
Quoted 2 lines
Because we can address the bitrot issue by simply building randconfigs, without even touching the kernel. So why do we need those linker tables?
As you noted its described better below.
Quoted 13 lines
Quoted 4 lines
+ * Linux's linker tables allows for developers to be selective over where one
+ * wishes to take advantage of the optional feature of forcing compilation and
+ * only linking in enabled features.
+ *Quoted 8 lines
+ * To use linker tables and to optionally take advantage of avoiding code
+ * bit-rot, feature code should be implemented in separate C files, and should
+ * be designed to always be compiled -- they should not be guarded with a C
+ * code #ifdefCONFIG_FOOstatements, consideration must also be taken for
+ * sub-features which depend on the mainCONFIG_FOOoption, as they will be
+ * disabled if they depend onCONFIG_FOOand therefore not compiled. To force
+ * compilation and only link when features are needed a new optional target
+ * table-y can be used on Makefiles, documented below.
Quoted 2 lines
Ok, this is more like it. Linker tables actually diminish the
Kconfigcomplexity. I'd lead with that.
OK will be sure to clarify all this and thanks for the typo fixes, etc.
Quoted 9 lines
Quoted 3 lines
+ * will result with the feature on your binary only if you've enabled
+ *CONFIG_FOO, however using table-$(CONFIG_FOO) will always force compilation,
+ * this is why avoiding code bit-rot is an optional fature for Linux linker"fature" - please run it through spellchecker.
Btw, I'm afraid this "table-$(CONFIG" thing might be misused by people wanting their stuff to be compile-tested and we'd end up practically building an allyesconfig each time.
This should be decided per subsystem maintainer.
Quoted 3 lines
So how can I disable those table-* things from even getting built? Avoid using table-y? But then everything declared table-y will be built unconditionally. I don't think I like that. :-\
I suppose we could make this configurable... But frankly I would prefer to instead just document that this use should be carefully considered instead, and let this be up to the maintainers. We can make it easily configurable so we can do that later becomes a required, I don't think its needed though given maintainers should use it only when needed.
Quoted 12 lines
include/asm-generic/tables.h
Quoted 8 lines
+ * tables.
+ */include/asm-generic/tables.h new file +5
-0+ +/** +* DOC: How linker tables simplify inits +* +* Traditionally, we would implement features in C code as follows: Ok, so *this* is your main reason for linker tables - not fixing the bit-rot problem. The text on the bit-rot problem should come second and be the byproduct of linker tables.
Will fix ordering.
Quoted 3 lines
Also, this section here should be the opening section in the document explaining linker tables. I'd like to read about what it is first, then read what else they're good for.
Sure.
Quoted 22 lines
Quoted 13 lines
+ *
+ *foo_init();
+ *
+ * You'd then have afoo.hwhich would have:
+ *
+ * #ifdefCONFIG_FOO
+ * #else
+ * static inline void foo(void) { }
+ * #endif
+ *
+ * With linker tables this is no longer necessary as your init routines would
+ * be implicit, you'd instead call:
+ *Quoted 8 lines
+ *
call_init_fns();
+ *
+ *call_init_fns()would call all functions present in your init table and if
+ * and only if foo.o gets linked in, then its initialisation function will be
+ * called, whether you use obj-$(CONFIG_FOO) or table-$(CONFIG_FOO).
+ *
+ * The linker script takes care of assembling the tables for us. All of our
+ * table sections have names of the format SECTION_NAME*.tbl.NAME.N. Here
Quoted 2 lines
The fact that you actually say "tbl" here shows again
SECTION_TYPE_TABLESis redundant.
I've nuked SECTION_TYPE_TABLES and SECTION_TYPE_RANGES
Quoted 10 lines
Quoted 5 lines
+/**
+ * DOC: Linker table helpers
+ *
+ * These are helpers for linker tables.
+ */I'm assuming those are all needed and we're not adding them just for completeness...
Otherwise, they'll bit-rot. :-))))
The ones we didn't have uses for yet I've nuked now.
Luis
Borislav Petkov
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 9 lines · Luis R. Rodriguez
Quoted 3 lines
So how can I disable those table-* things from even getting built? Avoid using table-y? But then everything declared table-y will be built unconditionally. I don't think I like that. :-\
I suppose we could make this configurable... But frankly I would prefer to instead just document that this use should be carefully considered instead, and let this be up to the maintainers. We can make it easily configurable so we can do that later becomes a required, I don't think its needed though given maintainers should use it only when needed.
You know how maintainers are just people, right? At least in most cases :-)
I think it would be better if it were machine-enforceable somehow. Maybe allow it only for core code and have a single, per-arch file arch/x86/linker_tables or so where all those statements are collected and can be eyeballed by more people. Dunno, just trying to think of something here...
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 11 lines · Borislav Petkov
Quoted 9 lines · Luis R. Rodriguez
Quoted 3 lines
So how can I disable those table-* things from even getting built? Avoid using table-y? But then everything declared table-y will be built unconditionally. I don't think I like that. :-\
I suppose we could make this configurable... But frankly I would prefer to instead just document that this use should be carefully considered instead, and let this be up to the maintainers. We can make it easily configurable so we can do that later becomes a required, I don't think its needed though given maintainers should use it only when needed.
Quoted 7 lines
You know how maintainers are just people, right? At least in most cases :-)
I think it would be better if it were machine-enforceable somehow. Maybe allow it only for core code and have a single, per-arch file
arch/x86/linker_tablesor so where all those statements are collected and can be eyeballed by more people. Dunno, just trying to think of something here...
OK I've added CONFIG_BUILD_AVOID_BITROT.
Luis
Borislav Petkov
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 1 line · Luis R. Rodriguez
OK I've added
CONFIG_BUILD_AVOID_BITROT.
What does that do?
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 4 lines · Borislav Petkov
Quoted 1 line · Luis R. Rodriguez
OK I've added
CONFIG_BUILD_AVOID_BITROT.What does that do?
Enabling it allows the forced compilation chosen by maintainers. Otherwise forced compilations with the new special targets are ignored. I've gone with table-obj-y and table-lib-y as we have to support both lib-y and obj-y respective targets.
lib/Kconfig.debug +24 -0
@@ -1895,6 +1895,30 @@ config PROVIDE_OHCI1394_DMA_INIT See Documentation/debugging-via-ohci1394.txt for more information. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated" + default y + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time slightly. Enabling this option helps avoid + code bit rot by taking advantage of the facilities provided and + enabled by using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-y + + Say Y unless you are a grumpy maintainer and don't trust other + maintainer's judgements on what code should always get compiled. + config BUILD_DOCSRC bool "Build targets in Documentation/ tree" depends on HEADERS_CHECK
scripts/Makefile.build +4 -3
@@ -91,7 +91,8 @@ modorder-target := $(obj)/modules.order # We keep a list of all modules in $(MODVERDIR) -__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y) $(table-y)) \ +__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y) \ + $(table-obj-y)) \ $(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \ $(subdir-ym) $(always) @:
@@ -325,8 +326,8 @@ cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $< $(obj)/%.o: $(src)/%.S $(objtool_obj) FORCE $(call if_changed_rule,as_o_S) -targets += $(real-objs-y) $(real-objs-m) $(lib-y) -targets += $(extra-y) $(table-y) $(MAKECMDGOALS) $(always) +targets += $(real-objs-y) $(real-objs-m) $(lib-y) $(table-lib-y) +targets += $(extra-y) $(table-obj-y) $(MAKECMDGOALS) $(always) # Linker scripts preprocessor (.lds.S -> .lds) # ---------------------------------------------------------------------------
scripts/Makefile.lib +10 -11
@@ -12,15 +12,14 @@ export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS) $(subdir-ccflags-y) # Figure out what we need to build from the various variables # =========================================================================== -# Linker tables objects always wish to be built to avoid bit-rot in -# code, but only linked in *iff* they were enabled. We accomplish this -# using pegging linker table objects into extra-y, which forces -# compilation and then using the respective table-y and table-m as -# as hints for things we do want enabled. Objects which we want to -# avoid linking in will be in table-, not table-y and table-m. -extra-y += $(table-) -obj-m += $(table-m) -obj-y += $(table-y) +ifeq ($(CONFIG_BUILD_AVOID_BITROT),y) +extra-y += $(table-obj-) $(table-lib-) +endif + +obj-m += $(table-obj-m) +obj-y += $(table-obj-y) +lib-m += $(table-lib-m) +lib-y += $(table-lib-y) # When an object is listed to be built compiled-in and modular, # only build the compiled-in version
@@ -82,8 +81,8 @@ real-objs-m := $(foreach m, $(obj-m), $(if $(strip $($(m:.o=-objs)) $($(m:.o=-y) # Add subdir path extra-y := $(addprefix $(obj)/,$(extra-y)) -table-y := $(addprefix $(obj)/,$(table-y)) -table-m := $(addprefix $(obj)/,$(table-m)) +table-obj-y := $(addprefix $(obj)/,$(table-obj-y)) +table-obj-m := $(addprefix $(obj)/,$(table-obj-m)) always := $(addprefix $(obj)/,$(always)) targets := $(addprefix $(obj)/,$(targets)) modorder := $(addprefix $(obj)/,$(modorder))
Borislav Petkov
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 10 lines · Luis R. Rodriguez
Quoted 4 lines · Borislav Petkov
Quoted 1 line · Luis R. Rodriguez
OK I've added
CONFIG_BUILD_AVOID_BITROT.What does that do?
Enabling it allows the forced compilation chosen by maintainers. Otherwise forced compilations with the new special targets are ignored.
Nice.
lib/Kconfig.debug config PROVIDE_OHCI1394_DMA_INIT · line 1899
Quoted 13 lines
I've gone with table-obj-y and table-lib-y as we have to support both lib-y and obj-y respective targets.
lib/Kconfig.debug +2
-0@@ -1895,6 +1895,30 @@ config PROVIDE_OHCI1394_DMA_INIT See Documentation/debugging-via-ohci1394.txt for more information. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated"
...annotated targets"
lib/Kconfig.debug config PROVIDE_OHCI1394_DMA_INIT · line 1908
Quoted 9 lines
lib/Kconfig.debug +9
-0+ default y + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time slightly. Enabling this option helps avoid
s/slightly//
:-)
lib/Kconfig.debug config PROVIDE_OHCI1394_DMA_INIT · line 1920
Quoted 12 lines
lib/Kconfig.debug +12
-0+ code bit rot by taking advantage of the facilities provided and + enabled by using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-y + + Say Y unless you are a grumpy maintainer and don't trust other + maintainer's judgements on what code should always get compiled.
... or you're running a tiny-config setup
... or you're an embedded, resource-constrained person
... or you simply don't want to have stuff which is forcibly enabled on you even if you're never going to need it
...
I got a million o'those :-)
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 44 lines · Borislav Petkov
Quoted 10 lines · Luis R. Rodriguez
Quoted 4 lines · Borislav Petkov
Quoted 1 line · Luis R. Rodriguez
OK I've added
CONFIG_BUILD_AVOID_BITROT.What does that do?
Enabling it allows the forced compilation chosen by maintainers. Otherwise forced compilations with the new special targets are ignored.
Nice.
lib/Kconfig.debug config PROVIDE_OHCI1394_DMA_INIT · line 1899
Quoted 13 lines
I've gone with table-obj-y and table-lib-y as we have to support both lib-y and obj-y respective targets.
lib/Kconfig.debug +2
-0@@ -1895,6 +1895,30 @@ config PROVIDE_OHCI1394_DMA_INIT See Documentation/debugging-via-ohci1394.txt for more information. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated"...annotated targets"
lib/Kconfig.debug config PROVIDE_OHCI1394_DMA_INIT · line 1908
Quoted 9 lines
lib/Kconfig.debug +9
-0+ default y + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time slightly. Enabling this option helps avoids/slightly//
:-)
Quoted 14 lines
lib/Kconfig.debug config PROVIDE_OHCI1394_DMA_INIT · line 1920
Quoted 12 lines
lib/Kconfig.debug +12
-0+ code bit rot by taking advantage of the facilities provided and + enabled by using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-y + + Say Y unless you are a grumpy maintainer and don't trust other + maintainer's judgements on what code should always get compiled.... or you're running a tiny-config setup
Even so, you don't link the compiled extra code so the only penalty here is when compiling, nothing more. And if you are compiling typically the cost here is just a few seconds.
Quoted 1 line
... or you're an embedded, resource-constrained person
For the compilation of th kernel ?
Quoted 3 lines
... or you simply don't want to have stuff which is forcibly enabled on you even if you're never going to need it
...
Which seems to be the same as the reason I noted ?
Quoted 1 line
I got a million o'those :-)
I can remove the grumpy maintainer description :)
Luis
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Borislav Petkov
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 3 lines · Luis R. Rodriguez
Even so, you don't link the compiled extra code so the only penalty here is when compiling, nothing more. And if you are compiling typically the cost here is just a few seconds.
Yeah, so let's make it clear that this is similar to COMPILE_TEST and people with fast machines and who don't mind building a couple more seconds longer, should enable it.
You don't want to be doing bit-rotting tests on small, weak machines, which barely get done with the build as it is. I have a 32-bit atom which takes hours to build a kernel. Enabling that there is not making the kernel build any more fun.
Quoted 5 lines
Quoted 3 lines
... or you simply don't want to have stuff which is forcibly enabled on you even if you're never going to need it
...Which seems to be the same as the reason I noted ?
No, the reason is we don't force stuff down people's throats just because we think we know better. Other people do that.
Instead, we help them make an informed decision by describing the feature as precisely as possible.
Quoted 1 line
I can remove the grumpy maintainer description :)
Yap :-)
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 8 lines · Borislav Petkov
Quoted 3 lines · Luis R. Rodriguez
Even so, you don't link the compiled extra code so the only penalty here is when compiling, nothing more. And if you are compiling typically the cost here is just a few seconds.
Yeah, so let's make it clear that this is similar to
COMPILE_TESTand people with fast machines and who don't mind building a couple more seconds longer, should enable it.
Sure, I'll also move it under COMPILE_TEST, and default it to n.
Quoted 14 lines
You don't want to be doing bit-rotting tests on small, weak machines, which barely get done with the build as it is. I have a 32-bit atom which takes hours to build a kernel. Enabling that there is not making the kernel build any more fun.
Quoted 5 lines
Quoted 3 lines
... or you simply don't want to have stuff which is forcibly enabled on you even if you're never going to need it
...Which seems to be the same as the reason I noted ?
No, the reason is we don't force stuff down people's throats just because we think we know better. Other people do that.
Quoted 6 lines
Instead, we help them make an informed decision by describing the feature as precisely as possible.
Quoted 1 line
I can remove the grumpy maintainer description :)
Yap :-)
Alright, how's this new description:
init/Kconfig +28 -0
@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-y + + Say Y if you have a decent build machine and would like to help test + building code for more subsystems. Say N if you do you not have a + good build machine or only want to compile what you've enabled for + your kernel. + + Enabling this option never increases the size of your kernel. + config COMPILE_TEST bool "Compile also drivers which will not load" depends on !UML
Borislav Petkov
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 7 lines · Luis R. Rodriguez
Alright, how's this new description:
init/Kconfig +0
-0
init/Kconfig config CROSS_COMPILE · line 61
Quoted 9 lines
init/Kconfig +6
-0@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has
"will always be compiled" is already absolute.
init/Kconfig config CROSS_COMPILE · line 64
Quoted 3 lines
init/Kconfig +3
-0+ been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred
s/This helps avoid code bit rot issues, u/U/
The bit-rot thing comes again below.
Quoted 9 lines
init/Kconfig +9
-0+ by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: +
init/Kconfig config CROSS_COMPILE · line 83
Quoted 10 lines
init/Kconfig +10
-0+ o table-obj-y + o table-lib-y + + Say Y if you have a decent build machine and would like to help test + building code for more subsystems. Say N if you do you not have a + good build machine or only want to compile what you've enabled for + your kernel. + + Enabling this option never increases the size of your kernel. +
Other than those minor formulation nits, yeah, nice!
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Re: [RFC v3 07/13] tables.h: add linker table support
Just some minor typos in descriptions I noticed below...
Quoted 11 lines · Borislav Petkov
Quoted 10 lines · Luis R. Rodriguez
Alright, how's this new description:
init/Kconfig +0
-0@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically.
Quoted 5 lines
init/Kconfig config CROSS_COMPILE · line 60
Quoted 5 lines
init/Kconfig +5
-0+config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n + help + If enabled then the the special table-* Makefile targets will always
"the the" -> "the"
Quoted 7 lines
init/Kconfig config CROSS_COMPILE · line 61
Quoted 1 line
init/Kconfig +1
-0+ be forced to be compiled even if their respective CONFIG_ option has"will always be compiled" is already absolute.
Quoted 3 lines
init/Kconfig +3
-0+ been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred
"considered"
Quoted 27 lines
s/This helps avoid code bit rot issues, u/U/
The bit-rot thing comes again below.
Quoted 9 lines
init/Kconfig +9
-0+ by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under: + + include/linux/tables.h + + The special targets supported are: +init/Kconfig config CROSS_COMPILE · line 83
Quoted 10 lines
init/Kconfig +10
-0+ o table-obj-y + o table-lib-y + + Say Y if you have a decent build machine and would like to help test + building code for more subsystems. Say N if you do you not have a + good build machine or only want to compile what you've enabled for + your kernel. + + Enabling this option never increases the size of your kernel. +Other than those minor formulation nits, yeah, nice!
Quoted 8 lines
Thanks.
--
Regards/Gruss,
Boris.ECO tip #101: Trim your mails when you reply.
--
-Kees
Signature · 7 lines
Kees Cook Nexus Security _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel
Greg KH
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
In reply to Luis R. RodriguezQuoted 13 lines · Luis R. Rodriguez
Alright, how's this new description:
init/Kconfig +3
-0@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n
init/Kconfig config CROSS_COMPILE · line 68
Quoted 10 lines
init/Kconfig +10
-0+ help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under:
As a kernel developer I have _no_ idea what this is trying to say at all, sorry.
What is a "specially annotated target"? Who is forcing it to be built? What does it mean if it isn't built?
init/Kconfig config CROSS_COMPILE · line 75
Quoted 7 lines
init/Kconfig +7
-0+ + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-y
What does this mean to me as a developer? What does it mean to a user who wants to figure out if it should be enabled or not?
init/Kconfig config CROSS_COMPILE · line 80
Quoted 5 lines
init/Kconfig +5
-0+ + Say Y if you have a decent build machine and would like to help test + building code for more subsystems. Say N if you do you not have a + good build machine or only want to compile what you've enabled for + your kernel.
How does this test different subsystems? How does disabling it not test them? Why would I care either way?
init/Kconfig config CROSS_COMPILE · line 82
Quoted 2 lines
init/Kconfig +2
-0+ + Enabling this option never increases the size of your kernel.
Then what does it do? Just burn electricity for no reason?
totally confused...
greg k-h
Re: [RFC v3 07/13] tables.h: add linker table support
Quoted 3 lines · Greg KH
init/Kconfig config CROSS_COMPILE · line 82
Quoted 1 line
init/Kconfig +1
-0+ Enabling this option never increases the size of your kernel.Then what does it do? Just burn electricity for no reason?
I think that this whole thing could be without loss of generality reformulated in a "allows for participating in compile-testing code efforts, without actually having to have all the compile-tested code present in the resulting kernel".
Signature · 2 lines
Jiri Kosina SUSE Labs
Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
In reply to Greg KHQuoted 11 lines · Greg KH
Quoted 10 lines · Luis R. Rodriguez
Alright, how's this new description:
init/Kconfig +0
-0@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically.
Quoted 16 lines
init/Kconfig config CROSS_COMPILE · line 68
Quoted 13 lines
init/Kconfig +13
-0+config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under:As a kernel developer I have _no_ idea what this is trying to say at all, sorry.
Hmm, wow OK, sorry, and I thought I was being too verbose...
OK so first, linker tables allow for the ability to help simplify initialization sequences so that you no longer have to add the respective static inline in header files to do nothing, instead you simply get your init routine for your feature pegged into the linker table or not at link time. If enabling your feature does not require structural changes, you could then safely enable compiling this feature all the time, and only allow linking when the feature was enabled. We don't have an easy way to express this in our build system, the new targets added lets you accomplish this.
Quoted 1 line
What is a "specially annotated target"?
The ones listed below, table-obj-y and table-lib-y
Quoted 1 line
Who is forcing it to be built?
It would be up to maintainers for each subsystem/feature to decide if they want to use the new targets or not within their subsystem.
Quoted 1 line
What does it mean if it isn't built?
If you have CONFIG_BUILD_AVOID_BITROT enabled and some code using the special targets do not get built it means the dependencies it has were not met.
Quoted 9 lines
init/Kconfig config CROSS_COMPILE · line 75
Quoted 7 lines
init/Kconfig +7
-0+ + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-yWhat does this mean to me as a developer?
It mean you can count on a bit more build test coverage by CONFIG_BUILD_AVOID_BITROT users. Using table-obj-y is functionally equivalent to doing:
extra-y += foo.o
obj-y += foo.o
The above new targets are just short hand annotations for the same. We could actually use another shorthand prefix other than table-, however linker tables help making more of these type of targets possible. For instance, on initialiation sequences you no longer have to add each line for each feature onto a set routine, rather you just get the initialization routine linked in or not. This lets us avoid cluttering C code and header code with #idefs, and as a side consequences also allows more targets to be compiled without implicating functionality.
As a developer you should take care to to use table-obj-y, or table-lib-y only if you are certain the target does not require structural changes.
Quoted 2 lines
What does it mean to a user
who wants to figure out if it should be enabled or not?
It depends on their build system capability and their goals. If they wish to be able to report build bugs and have a decent build system they can enable this. Otherwise they should disable it.
Quoted 6 lines
init/Kconfig config CROSS_COMPILE · line 80
Quoted 4 lines
init/Kconfig +4
-0+ Say Y if you have a decent build machine and would like to help test + building code for more subsystems. Say N if you do you not have a + good build machine or only want to compile what you've enabled for + your kernel.How does this test different subsystems?
By enabling this feature you compile kconfig symbols that typically are disabled by most users and which have been identified by maintainers as needing more build testing love. The extra kconfig symbols built are only built if the dependencies for them are met.
Maintainers for subsystems would have to identify if they have key pieces of software that typically get disabled, and that enabling them would not incur or require structural changes, which can use more build test love.
Quoted 1 line
How does disabling it not test them?
By disabling this feature you only compile kconfig symbols you have enabled for your kernel.
Quoted 1 line
Why would I care either way?
You would care if you aware of certain kconfig symbols that do not get much build test love.
Quoted 4 lines
init/Kconfig config CROSS_COMPILE · line 81
Quoted 2 lines
init/Kconfig +2
-0+ + Enabling this option never increases the size of your kernel.Then what does it do? Just burn electricity for no reason?
It enables maintainers to annotate through the build system certain kconfig symbol which should be built if CONFIG_BUILD_AVOID_BITROT is enabled and its symbol dependencies are met.
Luis
Greg KH
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 29 lines · Luis R. Rodriguez
Quoted 11 lines · Greg KH
Quoted 10 lines · Luis R. Rodriguez
Alright, how's this new description:
init/Kconfig +0
-0@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically.Quoted 16 lines
init/Kconfig config CROSS_COMPILE · line 68
Quoted 13 lines
init/Kconfig +13
-0+config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default n + help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under:As a kernel developer I have _no_ idea what this is trying to say at all, sorry.
Quoted 1 line
Hmm, wow OK, sorry, and I thought I was being too verbose...
All of your good explainations and detail need to go into the text itself. Responding to my questions is wonderful, but is not going to help anyone out who sees the config option for the first time, unless you change the text there.
Quoted 8 lines
OK so first, linker tables allow for the ability to help simplify initialization sequences so that you no longer have to add the respective static inline in header files to do nothing, instead you simply get your init routine for your feature pegged into the linker table or not at link time. If enabling your feature does not require structural changes, you could then safely enable compiling this feature all the time, and only allow linking when the feature was enabled. We don't have an easy way to express this in our build system, the new targets added lets you accomplish this.
I still don't understand, sorry.
As a kernel developer, why do I care about this? Who should care about this, a driver developer, subsystem developer, someone adding a syscall, an arch subsystem developer?
Quoted 3 lines
Quoted 1 line
What is a "specially annotated target"?
The ones listed below, table-obj-y and table-lib-y
circular logic doesn't work :)
Quoted 4 lines
Quoted 1 line
Who is forcing it to be built?
It would be up to maintainers for each subsystem/feature to decide if they want to use the new targets or not within their subsystem.
Ok, as a maintainer of a subsystem, I still have no idea what any of this means. But maybe I'm just don't understand kernel subsystem development...
Quoted 4 lines
Quoted 1 line
What does it mean if it isn't built?
If you have
CONFIG_BUILD_AVOID_BITROTenabled and some code using the special targets do not get built it means the dependencies it has were not met.
What "dependencies"?
Quoted 10 lines
Quoted 9 lines
init/Kconfig config CROSS_COMPILE · line 75
Quoted 7 lines
init/Kconfig +7
-0+ + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-yWhat does this mean to me as a developer?
Quoted 6 lines
It mean you can count on a bit more build test coverage by
CONFIG_BUILD_AVOID_BITROTusers. Using table-obj-y is functionally equivalent to doing:extra-y += foo.o
obj-y += foo.o
Ok, but why change this? What's the advantage? Are you going to now go and change all locations of the above in the tree to the table- versions? If not, why is this needed?
Quoted 10 lines
The above new targets are just short hand annotations for the same. We could actually use another shorthand prefix other than table-, however linker tables help making more of these type of targets possible. For instance, on initialiation sequences you no longer have to add each line for each feature onto a set routine, rather you just get the initialization routine linked in or not. This lets us avoid cluttering C code and header code with #idefs, and as a side consequences also allows more targets to be compiled without implicating functionality.
As a developer you should take care to to use table-obj-y, or table-lib-y only if you are certain the target does not require structural changes.
How am I supposed to be "certain"?
Quoted 6 lines
Quoted 2 lines
What does it mean to a user
who wants to figure out if it should be enabled or not?It depends on their build system capability and their goals. If they wish to be able to report build bugs and have a decent build system they can enable this. Otherwise they should disable it.
Why is this differnent from CONFIG_TEST build option we have today (or whatever it's called...)
Anyway, again, I have no idea what this is, nor how I should use it. And if I am the audience for this type of config option, well, perhaps it needs to be rethought...
thanks,
greg k-h
Luis R. Rodriguez
maintainerRe: [RFC v3 07/13] tables.h: add linker table support
Quoted 30 lines · Greg KH
Quoted 29 lines · Luis R. Rodriguez
Quoted 27 lines · Greg KH
Quoted 13 lines · Luis R. Rodriguez
Alright, how's this new description:
init/Kconfig +3
-0@@ -53,6 +53,34 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +config BUILD_AVOID_BITROT + bool "Always force building specially annotated targets" + default ninit/Kconfig config CROSS_COMPILE · line 68
Quoted 10 lines
init/Kconfig +10
-0+ help + If enabled then the the special table-* Makefile targets will always + be forced to be compiled even if their respective CONFIG_ option has + been disabled, but its objects will only be linked in if the same + respective CONFIG_ option has been enabled. This helps avoid code + bit rot issues, use for these targets should be carefully considred + by maintainers. You can safely enable this option at the expense of + increasing compile time. Enabling this option helps avoid code bit + rot by taking advantage of the facilities provided and enabled by + using linker tables documented under:As a kernel developer I have _no_ idea what this is trying to say at all, sorry.
Quoted 6 lines
Quoted 1 line
Hmm, wow OK, sorry, and I thought I was being too verbose...
All of your good explainations and detail need to go into the text itself. Responding to my questions is wonderful, but is not going to help anyone out who sees the config option for the first time, unless you change the text there.
Sure.
Quoted 9 lines
Quoted 8 lines
OK so first, linker tables allow for the ability to help simplify initialization sequences so that you no longer have to add the respective static inline in header files to do nothing, instead you simply get your init routine for your feature pegged into the linker table or not at link time. If enabling your feature does not require structural changes, you could then safely enable compiling this feature all the time, and only allow linking when the feature was enabled. We don't have an easy way to express this in our build system, the new targets added lets you accomplish this.
Quoted 5 lines
I still don't understand, sorry.
As a kernel developer, why do I care about this? Who should care about this, a driver developer, subsystem developer, someone adding a syscall, an arch subsystem developer?
I'll try to explain this more.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
What is a "specially annotated target"?
The ones listed below, table-obj-y and table-lib-y
circular logic doesn't work :)
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Who is forcing it to be built?
It would be up to maintainers for each subsystem/feature to decide if they want to use the new targets or not within their subsystem.
Ok, as a maintainer of a subsystem, I still have no idea what any of this means. But maybe I'm just don't understand kernel subsystem development...
Jeesh, OK, will give it one more go.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
What does it mean if it isn't built?
If you have
CONFIG_BUILD_AVOID_BITROTenabled and some code using the special targets do not get built it means the dependencies it has were not met.What "dependencies"?
Will elaborate.
Quoted 14 lines
Quoted 14 lines
Quoted 9 lines
init/Kconfig config CROSS_COMPILE · line 75
Quoted 7 lines
init/Kconfig +7
-0+ + include/linux/tables.h + + The special targets supported are: + + o table-obj-y + o table-lib-yWhat does this mean to me as a developer?
It mean you can count on a bit more build test coverage by
CONFIG_BUILD_AVOID_BITROTusers. Using table-obj-y is functionally equivalent to doing:
Quoted 6 lines
Quoted 2 lines
extra-y += foo.o
obj-y += foo.oOk, but why change this? What's the advantage? Are you going to now go and change all locations of the above in the tree to the table- versions? If not, why is this needed?
Hell no, the gain here is clear annotation of when this practice is used. Linker table use could make this practice more prevalent.
Quoted 8 lines
Quoted 8 lines
The above new targets are just short hand annotations for the same. We could actually use another shorthand prefix other than table-, however linker tables help making more of these type of targets possible. For instance, on initialiation sequences you no longer have to add each line for each feature onto a set routine, rather you just get the initialization routine linked in or not. This lets us avoid cluttering C code and header code with #idefs, and as a side consequences also allows more targets to be compiled without implicating functionality.
Quoted 4 lines
Quoted 2 lines
As a developer you should take care to to use table-obj-y, or table-lib-y only if you are certain the target does not require structural changes.
How am I supposed to be "certain"?
Compile testing is one easy way, but better yet understanding the code is best. The structural change complication was one consideration that came to mind.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
What does it mean to a user
who wants to figure out if it should be enabled or not?It depends on their build system capability and their goals. If they wish to be able to report build bugs and have a decent build system they can enable this. Otherwise they should disable it.
Why is this differnent from
CONFIG_TESTbuild option we have today (or whatever it's called...)
We could fold it under that, sure.
Quoted 3 lines
Anyway, again, I have no idea what this is, nor how I should use it. And if I am the audience for this type of config option, well, perhaps it needs to be rethought...
Alright, I'll rip all this code bit rot things out into its own separate patch for Kbuild changes, documentation, etc, and see if this helps. Otherwise we can evaluate if we should just drop it. Keep in mind that iPXE actually used it for this purpose and enabled it tree wide, since I knew it would likely not be a popular option for some I figured an optional build target would be better. The rest is up to me to try to explain then how and why some folks might want this. Linker tables just make it an easier practice to use due to the simplication of code from #ifdef statements on Kconfig symbols.
I'll address all this then separately in my next respin. It will be its own separate patch.
Luis
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Luis R. Rodriguez
maintainerRFC v3 8/13 firmware/Makefile: force recompilation if makefile changes
In reply to Luis R. RodriguezIf you modify the target asm we currently do not force the recompilation of the firmware files. The target asm is in the firmware/Makefile, peg this file as a dependency to require re-compilation of firmware targets when the asm changes.
v3: introduced in this series
--- firmware/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
firmware/Makefile +2 -1
@@ -176,7 +176,8 @@ quiet_cmd_fwbin = MK_FW $@ wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \ include/config/ppc32.h include/config/ppc64.h \ include/config/superh32.h include/config/superh64.h \ - include/config/x86_32.h include/config/x86_64.h) + include/config/x86_32.h include/config/x86_64.h \ + firmware/Makefile) $(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps) $(call cmd,fwbin,$(patsubst %.gen.S,%,$@))
Signature · 7 lines
2.8.4 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel
Luis R. Rodriguez
maintainerRFC v3 9/13 firmware: port built-in section to linker table
In reply to Luis R. RodriguezThis ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution.
This also demos the use of the .rodata (SECTION_RO) linker tables.
Tested with 0 built-in firmware, 1 and 2 built-in
firmwares successfully.
v3:
o explicitly include tables.h as we no longer include tables.h from sections.h
o use new section_tbl_asmtype() helper on firmware/Makefile to enable having to unfold things on our own.
v2: introduced this file in this version of the series
--- arch/x86/kernel/cpu/microcode/core.c | 8 ++++---- drivers/base/firmware_class.c | 12 ++++++------ firmware/Makefile | 4 +++- include/asm-generic/vmlinux.lds.h | 7 ------- 4 files changed, 13 insertions(+), 18 deletions(-)
arch/x86/kernel/cpu/microcode/core.c +4 -4
@@ -31,6 +31,7 @@#include <linux/cpu.h> #include <linux/fs.h> #include <linux/mm.h> +#include <linux/tables.h> #include <asm/microcode_intel.h> #include <asm/cpu_device_id.h>
@@ -91,15 +92,14 @@ static bool __init check_loader_disabled_bsp(void)return *res; } -extern struct builtin_fw __start_builtin_fw[]; -extern struct builtin_fw __end_builtin_fw[]; +DECLARE_LINKTABLE_RO(struct builtin_fw, builtin_fw);bool get_builtin_firmware (struct cpio_data *cd,const char *name) {#ifdef CONFIG_FW_LOADER -struct builtin_fw *b_fw; +const struct builtin_fw *b_fw; -for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { + LINKTABLE_FOR_EACH(b_fw, builtin_fw) {if (!strcmp (name, b_fw->name)) { cd->size = b_fw->size; cd->data = b_fw->data;
drivers/base/firmware_class.c +6 -6
@@ -30,6 +30,7 @@#include <linux/syscore_ops.h> #include <linux/reboot.h> #include <linux/security.h> +#include <linux/tables.h> #include <generated/utsrelease.h>
@@ -43,15 +44,14 @@ MODULE_LICENSE("GPL");#ifdef CONFIG_FW_LOADER -extern struct builtin_fw __start_builtin_fw[]; -extern struct builtin_fw __end_builtin_fw[]; +DEFINE_LINKTABLE_RO(struct builtin_fw, builtin_fw);static bool fw_get_builtin_firmware (struct firmware *fw,const char *name,void *buf,size_t size) { -struct builtin_fw *b_fw; +const struct builtin_fw *b_fw; -for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { + LINKTABLE_FOR_EACH(b_fw, builtin_fw) {if (strcmp (name, b_fw->name) ==0 ) { fw->size = b_fw->size; fw->data = b_fw->data;
@@ -67,9 +67,9 @@ static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,static bool fw_is_builtin_firmware (const struct firmware *fw) { -struct builtin_fw *b_fw; +const struct builtin_fw *b_fw; -for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) + LINKTABLE_FOR_EACH(b_fw, builtin_fw)if (fw->data == b_fw->data)return true;
firmware/Makefile +3 -1
@@ -155,6 +155,8 @@ quiet_cmd_fwbin = MK_FW $@ ASM_ALIGN=$(if $(CONFIG_64BIT),3,2); \ PROGBITS=$(if $(CONFIG_ARM),%,@)progbits; \ echo "/* Generated by firmware/Makefile */" > $@;\ + echo "\#include <asm/sections.h>" >>$@;\ + echo "\#include <asm/tables.h>" >>$@;\ echo " .section .rodata" >>$@;\ echo " .p2align $${ASM_ALIGN}" >>$@;\ echo "_fw_$${FWSTR}_bin:" >>$@;\
@@ -164,7 +166,7 @@ quiet_cmd_fwbin = MK_FW $@ echo " .p2align $${ASM_ALIGN}" >>$@;\ echo "_fw_$${FWSTR}_name:" >>$@;\ echo " .string \"$$FWNAME\"" >>$@;\ - echo " .section .builtin_fw,\"a\",$${PROGBITS}" >>$@;\ + echo " section_tbl_asmtype(SECTION_RODATA, builtin_fw, SECTION_ORDER_ANY, a,$${PROGBITS})" >>$@;\ echo " .p2align $${ASM_ALIGN}" >>$@;\ echo " $${ASM_WORD} _fw_$${FWSTR}_name" >>$@;\ echo " $${ASM_WORD} _fw_$${FWSTR}_bin" >>$@;\
include/asm-generic/vmlinux.lds.h +0 -7
@@ -313,13 +313,6 @@ VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .; \ } \ \ -/* Built-in firmware blobs */ \ - .builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \ - VMLINUX_SYMBOL(__start_builtin_fw) = .; \ - *(.builtin_fw) \ - VMLINUX_SYMBOL(__end_builtin_fw) = .; \ - } \ - \TRACEDATA \ \/* Kernel symbol table: Normal symbols */ \
Signature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 10/13 jump_label: port __jump_table to linker tables
In reply to Luis R. RodriguezMove the __jump_table from the a custom section solution to a generic solution, this avoiding extra vmlinux.lds.h customizations.
This also demos the use of the .data (SECTION_DATA) linker table and of the shared asm call push_section_tbl().
Built-in kernel functionality was tested with CONFIG_STATIC_KEYS_SELFTEST. Moduler kernel functionality was tested with CONFIG_TEST_STATIC_KEYS. Both work as expected.
Since __jump_table sections are also supported per module this also required expanding module-common.lds.S to capture and fold all .data.tlb.__jump_table.* onto the the section __jump_table -- in this case for modules need to keep a reference in place, given the alternative is to use DEFINE_LINKTABLE(struct jump_entry, __jump_table) per module -- and later through macro hacks instantiate the jump entries per module upon init. This is doable but we'd loose out on the sorting of the table using the linker, to sort we'd always still need to expand the module common linker script. An alternative mechanism is possible which would make these custom module sections extensions dynamic without requiring manual changes, this however is best done later through a separate evolution once linker tables are in place.
A careful reviewer may note that some architectures use "\n\t" to separate asm code, while others just use a new line. Upon review last time it was deemed reasonable to for all architectures to juse use "\n", this is defined as ASM_CMD_SEP, and if an architecture needs to override they can do so on their architecture sections.h prior to including asm-generic/sections.h
v3:
o More elaborate tests performed
o first modular support use case, module tested was CONFIG_TEST_STATIC_KEYS (lib/test_static_keys.ko), this required us to extend module-common.lds.S
o use generic push_section_tbl_any() for all architectures
o Makes use of ASM_CMD_SEP to enable architectures to override later if needed
o guard tables.h inclusion and table definition with __KERNEL__
v2: introduced in this series
--- arch/arm/include/asm/jump_label.h | 6 ++++-- arch/arm64/include/asm/jump_label.h | 6 ++++-- arch/mips/include/asm/jump_label.h | 6 ++++-- arch/powerpc/include/asm/jump_label.h | 8 +++++--- arch/s390/include/asm/jump_label.h | 6 ++++-- arch/sparc/include/asm/jump_label.h | 6 ++++-- arch/x86/include/asm/jump_label.h | 10 ++++++---- include/asm-generic/vmlinux.lds.h | 4 ---- include/linux/jump_label.h | 10 ++++++---- kernel/jump_label.c | 17 ++++++++++------- scripts/module-common.lds.S | 5 +++++ tools/objtool/special.c | 8 +++++++- 12 files changed, 59 insertions(+), 33 deletions(-)
arch/arm/include/asm/jump_label.h +4 -2
@@ -1,6 +1,8 @@#ifndef _ASM_ARM_JUMP_LABEL_H#define _ASM_ARM_JUMP_LABEL_H +#include <asm/tables.h> +#ifndef __ASSEMBLY__#include <linux/types.h>
@@ -12,7 +14,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran { asm_volatile_goto("1:\n\t" WASM(nop) "\n\t" - ".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) ".word 1b, %l[l_yes], %c0\n\t" ".popsection\n\t" : : "i" (&((char *)key)[branch]) : : l_yes);
@@ -26,7 +28,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool { asm_volatile_goto("1:\n\t" WASM(b) " %l[l_yes]\n\t" - ".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) ".word 1b, %l[l_yes], %c0\n\t" ".popsection\n\t" : : "i" (&((char *)key)[branch]) : : l_yes);
arch/arm64/include/asm/jump_label.h +4 -2
@@ -19,6 +19,8 @@#ifndef __ASM_JUMP_LABEL_H#define __ASM_JUMP_LABEL_H +#include <asm/tables.h> +#ifndef __ASSEMBLY__#include <linux/types.h>
@@ -29,7 +31,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool branch) { asm goto("1: nop\n\t" -".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw)".align 3\n\t" ".quad 1b, %l[l_yes], %c0\n\t" ".popsection\n\t"
@@ -43,7 +45,7 @@ l_yes: static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch) { asm goto("1: b %l[l_yes]\n\t" -".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw)".align 3\n\t" ".quad 1b, %l[l_yes], %c0\n\t" ".popsection\n\t"
arch/mips/include/asm/jump_label.h +4 -2
@@ -8,6 +8,8 @@#ifndef _ASM_MIPS_JUMP_LABEL_H#define _ASM_MIPS_JUMP_LABEL_H +#include <asm/tables.h> +#ifndef __ASSEMBLY__#include <linux/types.h>
@@ -30,7 +32,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran { asm_volatile_goto("1:\t" NOP_INSN "\n\t" "nop\n\t" - ".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) WORD_INSN " 1b, %l[l_yes], %0\n\t" ".popsection\n\t" : : "i" (&((char *)key)[branch]) : : l_yes);
@@ -44,7 +46,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool { asm_volatile_goto("1:\tj %l[l_yes]\n\t" "nop\n\t" - ".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) WORD_INSN " 1b, %l[l_yes], %0\n\t" ".popsection\n\t" : : "i" (&((char *)key)[branch]) : : l_yes);
arch/powerpc/include/asm/jump_label.h +5 -3
@@ -10,6 +10,8 @@* 2 of the License, or (at your option) any later version. */ +#include <asm/tables.h> +#ifndef __ASSEMBLY__#include <linux/types.h>
@@ -23,7 +25,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran { asm_volatile_goto("1:\n\t" "nop\n\t" - ".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) JUMP_ENTRY_TYPE "1b, %l[l_yes], %c0\n\t" ".popsection \n\t" : : "i" (&((char *)key)[branch]) : : l_yes);
@@ -37,7 +39,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool { asm_volatile_goto("1:\n\t" "b %l[l_yes]\n\t" - ".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) JUMP_ENTRY_TYPE "1b, %l[l_yes], %c0\n\t" ".popsection \n\t" : : "i" (&((char *)key)[branch]) : : l_yes);
@@ -62,7 +64,7 @@ struct jump_entry {#else #define ARCH_STATIC_BRANCH (LABEL ,KEY ) \ 1098: nop; \ - .pushsection __jump_table, "aw"; \ + push_section_tbl_any(SECTION_DATA, __jump_table, aw); \ FTR_ENTRY_LONG 1098b, LABEL, KEY; \ .popsection#endif
arch/s390/include/asm/jump_label.h +4 -2
@@ -1,6 +1,8 @@#ifndef _ASM_S390_JUMP_LABEL_H#define _ASM_S390_JUMP_LABEL_H +#include <asm/tables.h> +#ifndef __ASSEMBLY__#include <linux/types.h>
@@ -16,7 +18,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool branch) { asm_volatile_goto("0: brcl 0,"__stringify(JUMP_LABEL_NOP_OFFSET)"\n" -".pushsection __jump_table, \"aw\"\n" + push_section_tbl_any(SECTION_DATA, __jump_table, aw)".balign 8\n" ".quad 0b, %l[label], %0\n" ".popsection\n"
@@ -30,7 +32,7 @@ label: static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch) { asm_volatile_goto("0: brcl 15, %l[label]\n" -".pushsection __jump_table, \"aw\"\n" + push_section_tbl_any(SECTION_DATA, __jump_table, aw)".balign 8\n" ".quad 0b, %l[label], %0\n" ".popsection\n"
arch/sparc/include/asm/jump_label.h +4 -2
@@ -1,6 +1,8 @@#ifndef _ASM_SPARC_JUMP_LABEL_H#define _ASM_SPARC_JUMP_LABEL_H +#include <asm/tables.h> +#ifndef __ASSEMBLY__#include <linux/types.h>
@@ -12,7 +14,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran asm_volatile_goto("1:\n\t" "nop\n\t" "nop\n\t" -".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw)".align 4\n\t" ".word 1b, %l[l_yes], %c0\n\t" ".popsection \n\t"
@@ -28,7 +30,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool asm_volatile_goto("1:\n\t" "b %l[l_yes]\n\t" "nop\n\t" -".pushsection __jump_table, \"aw\"\n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw)".align 4\n\t" ".word 1b, %l[l_yes], %c0\n\t" ".popsection \n\t"
arch/x86/include/asm/jump_label.h +6 -4
@@ -1,6 +1,8 @@#ifndef _ASM_X86_JUMP_LABEL_H#define _ASM_X86_JUMP_LABEL_H +#include <asm/tables.h> +#ifndef HAVE_JUMP_LABEL /* * For better or for worse, if jump labels (the gcc extension) are missing,
@@ -34,7 +36,7 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran { asm_volatile_goto("1:" ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t" -".pushsection __jump_table, \"aw\" \n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) _ASM_ALIGN"\n\t" _ASM_PTR"1b, %l[l_yes], %c0 + %c1 \n\t" ".popsection \n\t"
@@ -50,7 +52,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool asm_volatile_goto("1:" ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t" "2:\n\t" -".pushsection __jump_table, \"aw\" \n\t" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) _ASM_ALIGN"\n\t" _ASM_PTR"1b, %l[l_yes], %c0 + %c1 \n\t" ".popsection \n\t"
@@ -85,7 +87,7 @@ struct jump_entry { .else .byte STATIC_KEY_INIT_NOP .endif - .pushsection __jump_table, "aw" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) _ASM_ALIGN _ASM_PTR .Lstatic_jump_\@, \target, \key .popsection
@@ -101,7 +103,7 @@ struct jump_entry { .long \target - .Lstatic_jump_after_\@ .Lstatic_jump_after_\@: .endif - .pushsection __jump_table, "aw" + push_section_tbl_any(SECTION_DATA, __jump_table, aw) _ASM_ALIGN _ASM_PTR .Lstatic_jump_\@, \target, \key + 1 .popsection
include/asm-generic/vmlinux.lds.h +0 -4
@@ -210,10 +210,6 @@STRUCT_ALIGN (); \ *(__tracepoints) \/* implement dynamic printk debug */ \ - . = ALIGN(8); \ - VMLINUX_SYMBOL(__start___jump_table) = .; \ - *(__jump_table ) \ - VMLINUX_SYMBOL(__stop___jump_table) = .; \ . = ALIGN(8); \ VMLINUX_SYMBOL(__start___verbose) = .; \ *(__verbose) \
include/linux/jump_label.h +6 -4
@@ -130,8 +130,10 @@ static __always_inline bool static_key_true(struct static_key *key)return !arch_static_branch (key, true); } -extern struct jump_entry __start___jump_table[]; -extern struct jump_entry __stop___jump_table[]; +#ifndef __KERNEL__ +#include <linux/tables.h> + DECLARE_LINKTABLE(struct jump_entry, __jump_table); +#endif /* __KERNEL__ */ extern void jump_label_init (void );extern void jump_label_lock (void );
@@ -384,6 +386,6 @@ extern bool ____wrong_branch_error(void);#define static_branch_enable (x) static_key_enable(&(x)->key)#define static_branch_disable (x) static_key_disable(&(x)->key) -#endif /* _LINUX_JUMP_LABEL_H */ -#endif /* __ASSEMBLY__ */ + +#endif /* _LINUX_JUMP_LABEL_H */
kernel/jump_label.c +10 -7
@@ -15,9 +15,12 @@#include <linux/static_key.h> #include <linux/jump_label_ratelimit.h> #include <linux/bug.h> +#include <linux/tables.h> #ifdef HAVE_JUMP_LABEL +DEFINE_LINKTABLE(struct jump_entry, __jump_table); +/* mutex to protect coming/going of the the jump_label table */ static DEFINE_MUTEX (jump_label_mutex);
@@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key *key,void __init jump_label_init (void ) { -struct jump_entry *iter_start = __start___jump_table; -struct jump_entry *iter_stop = __stop___jump_table;struct static_key *key =NULL ;struct jump_entry *iter;
@@ -289,9 +290,10 @@ void __init jump_label_init(void)BUILD_BUG_ON ((int )ATOMIC_INIT (1 ) !=1 );jump_label_lock (); -jump_label_sort_entries (iter_start, iter_stop); +jump_label_sort_entries (LINUX_SECTION_START (__jump_table), +LINUX_SECTION_END (__jump_table)); -for (iter = iter_start; iter < iter_stop; iter++) { + LINKTABLE_FOR_EACH(iter, __jump_table) {struct static_key *iterk;/* rewrite NOPs */
@@ -533,8 +535,9 @@ early_initcall(jump_label_init_module);*/ int jump_label_text_reserved (void *start,void *end) { -int ret =__jump_label_text_reserved (__start___jump_table, - __stop___jump_table, start, end); +int ret =__jump_label_text_reserved (LINUX_SECTION_START (__jump_table), +LINUX_SECTION_END (__jump_table), + start, end);if (ret)return ret;
@@ -547,7 +550,7 @@ int jump_label_text_reserved(void *start, void *end)static void jump_label_update (struct static_key *key) { -struct jump_entry *stop = __stop___jump_table; +struct jump_entry *stop =LINUX_SECTION_END (__jump_table);struct jump_entry *entry =static_key_entries (key);#ifdef CONFIG_MODULES struct module *mod;
scripts/module-common.lds.S +5 -0
@@ -3,6 +3,10 @@ * Archs are free to supply their own linker scripts. ld will * combine them automatically. */ + +#include <asm/sections.h> +#include <asm/tables.h> + SECTIONS { /DISCARD/ : { *(.discard) }
@@ -16,6 +20,7 @@ SECTIONS { __kcrctab_unused 0 : { *(SORT(___kcrctab_unused+*)) } __kcrctab_unused_gpl 0 : { *(SORT(___kcrctab_unused_gpl+*)) } __kcrctab_gpl_future 0 : { *(SORT(___kcrctab_gpl_future+*)) } + __jump_table 0 : { *(SORT(SECTION_TBL(SECTION_DATA, __jump_table, *))) } . = ALIGN(8); .init_array 0 : { *(SORT(.init_array.*)) *(.init_array) }
tools/objtool/special.c +7 -1
@@ -26,6 +26,10 @@#include "special.h" #include "warn.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/asm-generic/tables.h" +#include "../../include/linux/stringify.h" +#define EX_ENTRY_SIZE 12#define EX_ORIG_OFFSET 0#define EX_NEW_OFFSET 4
@@ -63,7 +67,9 @@ struct special_entry entries[] = { .feature = ALT_FEATURE_OFFSET, }, { - .sec = "__jump_table", + .sec = __stringify(SECTION_TBL(SECTION_DATA, + __jump_table, + SECTION_ORDER_ANY)), .jump_or_nop = true, .size = JUMP_ENTRY_SIZE, .orig = JUMP_ORIG_OFFSET,
Signature · 1 line
2.8.4
Re: [RFC v3 10/13] jump_label: port __jump_table to linker tables
Quoted 16 lines · Luis R. Rodriguez
tools/objtool/special.c +4
-0@@ -26,6 +26,10 @@#include "special.h" #include "warn.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/asm-generic/tables.h" +#include "../../include/linux/stringify.h" +#define EX_ENTRY_SIZE 12#define EX_ORIG_OFFSET 0#define EX_NEW_OFFSET 4
tools/objtool/special.c struct special_entry entries[] = { · line 75
Quoted 10 lines
tools/objtool/special.c +3
-1@@ -63,7 +67,9 @@ struct special_entry entries[] = { .feature = ALT_FEATURE_OFFSET, }, { - .sec = "__jump_table", + .sec = __stringify(SECTION_TBL(SECTION_DATA, + __jump_table, + SECTION_ORDER_ANY)), .jump_or_nop = true, .size = JUMP_ENTRY_SIZE, .orig = JUMP_ORIG_OFFSET,
(continuing our discussion from another thread...)
I think tools code isn't allowed to include kernel files because the tools subdirectory is supposed to be completely independent.
As far as I can tell, the section name will always be ".data.tbl.__jump_table.any". Is that true? If so, any reason why we can't just hard-code the string here? As you saw, if the string changes, objtool will complain and 0-day will report it.
Signature · 1 line
Josh
Luis R. Rodriguez
maintainerRe: [RFC v3 10/13] jump_label: port __jump_table to linker tables
Quoted 30 lines · Josh Poimboeuf
Quoted 16 lines · Luis R. Rodriguez
tools/objtool/special.c +4
-0@@ -26,6 +26,10 @@#include "special.h" #include "warn.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/asm-generic/tables.h" +#include "../../include/linux/stringify.h" +#define EX_ENTRY_SIZE 12#define EX_ORIG_OFFSET 0#define EX_NEW_OFFSET 4tools/objtool/special.c struct special_entry entries[] = { · line 75
Quoted 10 lines
tools/objtool/special.c +3
-1@@ -63,7 +67,9 @@ struct special_entry entries[] = { .feature = ALT_FEATURE_OFFSET, }, { - .sec = "__jump_table", + .sec = __stringify(SECTION_TBL(SECTION_DATA, + __jump_table, + SECTION_ORDER_ANY)), .jump_or_nop = true, .size = JUMP_ENTRY_SIZE, .orig = JUMP_ORIG_OFFSET,(continuing our discussion from another thread...)
Quoted 2 lines
I think tools code isn't allowed to include kernel files because the tools subdirectory is supposed to be completely independent.
That was also the case for userpsace tools in scripts/ -- for instance scripts/mod/modpost.c made an exception. What I've proposed here to keep things simple was to ensure -UKERNEL is passed and then only include files we know will work.
Refer to the patch "kprobes: port .kprobes.text to section range" in this series for an extension of the scripts/mod/modpost.c kernel headers use.
Quoted 3 lines
As far as I can tell, the section name will always be ".data.tbl.__jump_table.any". Is that true? If so, any reason why we can't just hard-code the string here?
Its a fair strategy, however if upstream changes the order name we'd have to hand code this as well, by using a macro we keep it all in one place.
Quoted 2 lines
As you saw, if the string
changes, objtool will complain and 0-day will report it.
Indeed, which is why I was hoping to instead stick to a standard sections set of header files that lets us get these in on place. The only place I hand coded in this series was in the perl file scripts/recordmcount.pl but I suppose if we wanted to get creative we could even generate a header for it too.
If we want to avoid all this hacker include stuff another option is to *generate* each respective sections.h for the kernel, and also, one for tools, and one for perl. What do you think?
Luis
Re: [RFC v3 10/13] jump_label: port __jump_table to linker tables
Quoted 34 lines · Luis R. Rodriguez
Quoted 30 lines · Josh Poimboeuf
Quoted 16 lines · Luis R. Rodriguez
tools/objtool/special.c +4
-0@@ -26,6 +26,10 @@#include "special.h" #include "warn.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/asm-generic/tables.h" +#include "../../include/linux/stringify.h" +#define EX_ENTRY_SIZE 12#define EX_ORIG_OFFSET 0#define EX_NEW_OFFSET 4tools/objtool/special.c struct special_entry entries[] = { · line 75
Quoted 10 lines
tools/objtool/special.c +3
-1@@ -63,7 +67,9 @@ struct special_entry entries[] = { .feature = ALT_FEATURE_OFFSET, }, { - .sec = "__jump_table", + .sec = __stringify(SECTION_TBL(SECTION_DATA, + __jump_table, + SECTION_ORDER_ANY)), .jump_or_nop = true, .size = JUMP_ENTRY_SIZE, .orig = JUMP_ORIG_OFFSET,(continuing our discussion from another thread...)
Quoted 2 lines
I think tools code isn't allowed to include kernel files because the tools subdirectory is supposed to be completely independent.
Quoted 8 lines
That was also the case for userpsace tools in
scripts/-- for instancescripts/mod/modpost.cmade an exception. What I've proposed here to keep things simple was to ensure -UKERNEL is passed and then only include files we know will work.Refer to the patch "kprobes: port .kprobes.text to section range" in this series for an extension of the
scripts/mod/modpost.ckernel headers use.
I think the rule of separating code is stricter for tools/ than it is for scripts/. The scripts are generally kernel-specific whereas the tools are independent. I believe the goal is to be able to copy them out of the kernel tree and still be able to compile them.
Quoted 7 lines
Quoted 3 lines
As far as I can tell, the section name will always be ".data.tbl.__jump_table.any". Is that true? If so, any reason why we can't just hard-code the string here?
Its a fair strategy, however if upstream changes the order name we'd have to hand code this as well, by using a macro we keep it all in one place.
Hm, do you expect the section name to change often?
Quoted 5 lines
Quoted 2 lines
As you saw, if the string
changes, objtool will complain and 0-day will report it.Indeed, which is why I was hoping to instead stick to a standard sections set of header files that lets us get these in on place.
Actually, I meant that obtool reporting the change would be a good thing, in favor of just hard-coding the string. It lets objtool do its job of letting us know when something changes, like it did today.
Quoted 7 lines
The only place I hand coded in this series was in the perl file
scripts/recordmcount.plbut I suppose if we wanted to get creative we could even generate a header for it too.If we want to avoid all this hacker include stuff another option is to *generate* each respective
sections.hfor the kernel, and also, one for tools, and one for perl. What do you think?
If the generated files aren't checked into git, tools/ will rely on kernel files and will no longer be independent. If they *are* checked in, then we have to keep the files in sync. Either way it sounds like overkill, just to avoid hard-coding a string for which objtool will already warn if it changes.
Signature · 1 line
Josh
Luis R. Rodriguez
maintainerRe: [RFC v3 10/13] jump_label: port __jump_table to linker tables
Quoted 40 lines · Josh Poimboeuf
Quoted 39 lines · Luis R. Rodriguez
Quoted 30 lines · Josh Poimboeuf
Quoted 16 lines · Luis R. Rodriguez
tools/objtool/special.c +4
-0@@ -26,6 +26,10 @@#include "special.h" #include "warn.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/asm-generic/tables.h" +#include "../../include/linux/stringify.h" +#define EX_ENTRY_SIZE 12#define EX_ORIG_OFFSET 0#define EX_NEW_OFFSET 4tools/objtool/special.c struct special_entry entries[] = { · line 75
Quoted 10 lines
tools/objtool/special.c +3
-1@@ -63,7 +67,9 @@ struct special_entry entries[] = { .feature = ALT_FEATURE_OFFSET, }, { - .sec = "__jump_table", + .sec = __stringify(SECTION_TBL(SECTION_DATA, + __jump_table, + SECTION_ORDER_ANY)), .jump_or_nop = true, .size = JUMP_ENTRY_SIZE, .orig = JUMP_ORIG_OFFSET,(continuing our discussion from another thread...)
Quoted 2 lines
I think tools code isn't allowed to include kernel files because the tools subdirectory is supposed to be completely independent.
That was also the case for userpsace tools in
scripts/-- for instancescripts/mod/modpost.cmade an exception. What I've proposed here to keep things simple was to ensure -UKERNEL is passed and then only include files we know will work.
Quoted 8 lines
Quoted 3 lines
Refer to the patch "kprobes: port .kprobes.text to section range" in this series for an extension of the
scripts/mod/modpost.ckernel headers use.I think the rule of separating code is stricter for
tools/than it is forscripts/. The scripts are generally kernel-specific whereas the tools are independent. I believe the goal is to be able to copy them out of the kernel tree and still be able to compile them.
I see.
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
As far as I can tell, the section name will always be ".data.tbl.__jump_table.any". Is that true? If so, any reason why we can't just hard-code the string here?
Its a fair strategy, however if upstream changes the order name we'd have to hand code this as well, by using a macro we keep it all in one place.
Hm, do you expect the section name to change often?
Nope, if anything only upon deployment on major distributions due to some perhaps compatibility thing with custom hacks folks may have carried and this just ended up clashing with. The only other case I can think of a need for a change would be if upstream linkers supported something similar for another brand of section names, with the added gain that we would then not even need the 2 new lines on the kernel linker script for section ranges and tables per section.
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
As you saw, if the string
changes, objtool will complain and 0-day will report it.Indeed, which is why I was hoping to instead stick to a standard sections set of header files that lets us get these in on place.
Actually, I meant that obtool reporting the change would be a good thing, in favor of just hard-coding the string. It lets objtool do its job of letting us know when something changes, like it did today.
Getting a report so you can fix something is one reason to have a tool, having it so you can inspect changes is another. So it depends what uses there are for objtool. I take it that for this case we do want upstream objtool to embrace the new section name to avoid further reports as issues ?
Quoted 8 lines
Quoted 7 lines
The only place I hand coded in this series was in the perl file
scripts/recordmcount.plbut I suppose if we wanted to get creative we could even generate a header for it too.If we want to avoid all this hacker include stuff another option is to *generate* each respective
sections.hfor the kernel, and also, one for tools, and one for perl. What do you think?
Quoted 5 lines
If the generated files aren't checked into git,
tools/will rely on kernel files and will no longer be independent. If they *are* checked in, then we have to keep the files in sync. Either way it sounds like overkill, just to avoid hard-coding a string for which objtool will already warn if it changes.
We can open code the string, that's fine. In retrospect since things won't change often that keeps things simple.
Luis
Luis R. Rodriguez
maintainerRFC v3 11/13 dynamic_debug: port to use linker tables
In reply to Luis R. RodriguezThis removes the custom vmlinux.lds.h hacks and uses the generalized solution for .data (SECTION_DATA) entries.
This is much more potential for further fine tuning here though in the future. For instance, linker tables enable an extra postfix for order level annotations, this could easily be used as the KBUILD_MODNAME and with a bit of linker table changes we may be able to get a direct O(1) count of the entries for that KBUILD_MODNAME: it would just be a count on the number of entries for the given order level. This should help make dynamic_debug_init() cleaner and also reduce the amount of time it takes at boot time. Instead of iterating over each print until we have all for a KBUILD_MODNAME, we'd instead directly operate on each KBUILD_MODNAME directly.
Tested dynamic debug with dyndbg query ana debugfs control and it works as expected, for both built-in code and modules.
v3: added modular support
v2: introduced this patch into the series
--- include/asm-generic/vmlinux.lds.h | 5 ----- include/linux/dynamic_debug.h | 5 +++-- lib/dynamic_debug.c | 13 ++++++------- scripts/module-common.lds.S | 1 + 4 files changed, 10 insertions(+), 14 deletions(-)
include/asm-generic/vmlinux.lds.h +0 -5
@@ -209,11 +209,6 @@ *(.data.unlikely) \STRUCT_ALIGN (); \ *(__tracepoints ) \ -/* implement dynamic printk debug */ \ - . = ALIGN(8); \ - VMLINUX_SYMBOL(__start___verbose) = .; \ - *(__verbose ) \ - VMLINUX_SYMBOL(__stop___verbose) = .; \ LIKELY_PROFILE() \ BRANCH_PROFILE() \TRACE_PRINTKS () \
include/linux/dynamic_debug.h +3 -2
@@ -4,6 +4,7 @@#if defined(CC_HAVE_ASM_GOTO ) && defined(CONFIG_JUMP_LABEL )#include <linux/jump_label.h> #endif +#include <linux/tables.h> /* * An instance of this structure is created in a special
@@ -50,6 +51,7 @@ int ddebug_add_module(struct _ddebug *tab, unsigned int n, const char *modname);#if defined(CONFIG_DYNAMIC_DEBUG ) +DECLARE_LINKTABLE(struct _ddebug, __verbose);extern int ddebug_remove_module (const char *mod_name); extern __printf(2, 3) void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...);
@@ -71,8 +73,7 @@ void __dynamic_netdev_dbg(struct _ddebug *descriptor, const char *fmt, ...);#define DEFINE_DYNAMIC_DEBUG_METADATA_KEY (name, fmt, key, init) \ - static struct _ddebug __aligned(8) \ - __attribute__((section("__verbose"))) name = { \ + static LINKTABLE(__verbose, SECTION_ORDER_ANY) name = { \ .modname = KBUILD_MODNAME, \ .function = __func__, \ .filename = __FILE__, \
lib/dynamic_debug.c +6 -7
@@ -37,8 +37,7 @@#include <linux/device.h> #include <linux/netdevice.h> -extern struct _ddebug __start___verbose[]; -extern struct _ddebug __stop___verbose[]; +DEFINE_LINKTABLE(struct _ddebug, __verbose);struct ddebug_table {struct list_head link;
@@ -978,14 +977,14 @@ static int __init dynamic_debug_init(void)int n =0 , entries =0 , modct =0 ;int verbose_bytes =0 ; -if (__start___verbose == __stop___verbose) { -pr_warn ("_ddebug table is empty in a CONFIG_DYNAMIC_DEBUG build\n" ); +if (LINUX_SECTION_EMPTY (__verbose)) { +pr_warn ("dynamic debug linker table empty on CONFIG_DYNAMIC_DEBUG build\n" );return 1 ; } - iter = __start___verbose; + iter =LINUX_SECTION_START (__verbose); modname = iter->modname; iter_start = iter; -for (; iter < __stop___verbose; iter++) { + LINKTABLE_FOR_EACH(iter, __verbose) { entries++; verbose_bytes +=strlen (iter->modname) +strlen (iter->function) +strlen (iter->filename) +strlen (iter->format);
@@ -1008,7 +1007,7 @@ static int __init dynamic_debug_init(void) ddebug_init_success =1 ;vpr_info ("%d modules, %d entries and %d bytes in ddebug tables, %d bytes in (readonly) verbose section\n" , modct, entries, (int )(modct *sizeof (struct ddebug_table )), - verbose_bytes + (int )(__stop___verbose - __start___verbose)); + verbose_bytes + (int )(LINUX_SECTION_SIZE (__verbose)));/* apply ddebug_query boot param, dont unload tables on err */ if (ddebug_setup_string[0 ] !='\0' ) {
scripts/module-common.lds.S +1 -0
@@ -21,6 +21,7 @@ SECTIONS { __kcrctab_unused_gpl 0 : { *(SORT(___kcrctab_unused_gpl+*)) } __kcrctab_gpl_future 0 : { *(SORT(___kcrctab_gpl_future+*)) } __jump_table 0 : { *(SORT(SECTION_TBL(SECTION_DATA, __jump_table, *))) } + __verbose 0 : { *(SORT(SECTION_TBL(SECTION_DATA, __verbose, *))) } . = ALIGN(8); .init_array 0 : { *(SORT(.init_array.*)) *(.init_array) }
Signature · 1 line
2.8.4
Luis R. Rodriguez
maintainerRFC v3 12/13 kprobes: port .kprobes.text to section range
In reply to Luis R. Rodriguezkprobe makes use of two custom sections, each custom section is folded into one of the standard Linux sections types as follows, it currently relies on the linker script to fold the custom section onto the respective Linux section:
type Linux-section custom section name begin end table .init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist range .text .kprobes.text __kprobes_text_start __kprobes_text_end
This ports the .kprobes.text custom section to the standard Linux ranges API allowing us remove all the custom kprobe section declarations from the linker script.
Tested with CONFIG_KPROBES_SANITY_TEST, it passes with:
Kprobe smoke test: started
Kprobe smoke test: passed successfully
Then tested CONFIG_SAMPLE_KPROBES on do_fork, and the kprobe bites and kicks as expected.
Also ran ./ftracetest with no issues:
$ sudo ./ftracetest === Ftrace unit tests === [1] Basic trace file check [PASS] [2] Basic test for tracers [PASS] [3] Basic trace clock test [PASS] [4] Basic event tracing check [PASS] [5] event tracing - enable/disable with event level files [PASS] [6] event tracing - restricts events based on pid [PASS] [7] event tracing - enable/disable with subsystem level files [PASS] [8] event tracing - enable/disable with top level files [PASS] [9] ftrace - function graph filters with stack tracer [PASS] [10] ftrace - function graph filters [PASS] [11] ftrace - function profiler with function tracing [PASS] [12] Test creation and deletion of trace instances while setting an event[PASS] [13] Test creation and deletion of trace instances [PASS] [14] Kprobe dynamic event - adding and removing [PASS] [15] Kprobe dynamic event - busy event check [PASS] [16] Kprobe dynamic event with arguments [PASS] [17] Kprobe dynamic event with function tracer [PASS] [18] Kretprobe dynamic event with arguments [PASS] [19] event trigger - test event enable/disable trigger [PASS] [20] event trigger - test trigger filter [PASS] [21] event trigger - test histogram modifiers [PASS] [22] event trigger - test histogram trigger [PASS] [23] event trigger - test multiple histogram triggers [PASS] [24] event trigger - test snapshot-trigger [PASS] [25] event trigger - test stacktrace-trigger [PASS] [26] event trigger - test traceon/off trigger [PASS]
# of passed: 26 # of failed: 0 # of unresolved: 0 # of untested: 0 # of unsupported: 0 # of xfailed: 0 # of undefined(test bug): 0
v3:
o after v2 arch/arm/kernel/vmlinux-xip.lds.S got kprobe support, this just removes the custom linker script reference to kprobes as that is no longer needed with linker tables.
o split kprobe linker table and kprobe section ranges use into two separate patches. This should make it easier to review and also demos both distinct use types, one a linker table another a simple section range.
v2: introduced this patch in this series
--- arch/arc/kernel/vmlinux.lds.S | 1 - arch/arm/kernel/entry-armv.S | 3 ++- arch/arm/kernel/vmlinux-xip.lds.S | 1 - arch/arm/kernel/vmlinux.lds.S | 1 - arch/avr32/kernel/entry-avr32b.S | 5 +++-- arch/avr32/kernel/vmlinux.lds.S | 1 - arch/blackfin/kernel/vmlinux.lds.S | 1 - arch/c6x/kernel/vmlinux.lds.S | 1 - arch/hexagon/kernel/vmlinux.lds.S | 1 - arch/ia64/kernel/jprobes.S | 3 ++- arch/ia64/kernel/vmlinux.lds.S | 1 - arch/ia64/lib/flush.S | 5 +++-- arch/metag/kernel/vmlinux.lds.S | 1 - arch/microblaze/kernel/vmlinux.lds.S | 1 - arch/mips/kernel/vmlinux.lds.S | 1 - arch/mn10300/kernel/vmlinux.lds.S | 1 - arch/nios2/kernel/vmlinux.lds.S | 1 - arch/openrisc/kernel/vmlinux.lds.S | 1 - arch/parisc/kernel/vmlinux.lds.S | 1 - arch/powerpc/include/asm/ppc_asm.h | 7 ++++--- arch/powerpc/kernel/vmlinux.lds.S | 1 - arch/s390/kernel/entry.S | 5 +++-- arch/s390/kernel/kprobes.c | 6 +++--- arch/s390/kernel/mcount.S | 2 +- arch/s390/kernel/vmlinux.lds.S | 1 - arch/score/kernel/vmlinux.lds.S | 1 - arch/sh/kernel/vmlinux.lds.S | 1 - arch/sparc/kernel/vmlinux.lds.S | 1 - arch/sparc/mm/ultra.S | 3 ++- arch/tile/kernel/vmlinux.lds.S | 1 - arch/x86/kernel/kprobes/core.c | 11 +++++------ arch/x86/kernel/vmlinux.lds.S | 1 - include/asm-generic/sections.h | 2 -- include/asm-generic/vmlinux.lds.h | 6 ------ include/linux/compiler.h | 2 +- include/linux/kprobes.h | 3 +++ kernel/kprobes.c | 6 ++++-- scripts/Makefile | 1 + scripts/mod/Makefile | 2 ++ scripts/mod/modpost.c | 8 +++++++- scripts/recordmcount.c | 7 ++++++- scripts/recordmcount.pl | 2 +- 42 files changed, 53 insertions(+), 58 deletions(-)
arch/arc/kernel/vmlinux.lds.S +0 -1
@@ -98,7 +98,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT *(.fixup) *(.gnu.warning) }
arch/arm/kernel/entry-armv.S +2 -1
@@ -34,6 +34,7 @@ #include "entry-header.S" #include <asm/entry-macro-multi.S> #include <asm/probes.h> +#include <asm/ranges.h> /* * Interrupt handling.
@@ -83,7 +84,7 @@ .endm #ifdef CONFIG_KPROBES - .section .kprobes.text,"ax",%progbits + section_rng_asmtype(SECTION_TEXT, kprobes, ax, %progbits) #else .text #endif
arch/arm/kernel/vmlinux-xip.lds.S +0 -1
@@ -99,7 +99,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT *(.gnu.warning) *(.glue_7) *(.glue_7t)
arch/arm/kernel/vmlinux.lds.S +0 -1
@@ -113,7 +113,6 @@ SECTIONS SCHED_TEXT LOCK_TEXT HYPERVISOR_TEXT - KPROBES_TEXT *(.gnu.warning) *(.glue_7) *(.glue_7t)
arch/avr32/kernel/entry-avr32b.S +3 -2
@@ -23,6 +23,7 @@ #include <asm/sysreg.h> #include <asm/thread_info.h> #include <asm/unistd.h> +#include <asm/ranges.h> #ifdef CONFIG_PREEMPT # define preempt_stop mask_interrupts
@@ -605,7 +606,7 @@ fault_exit_work: brcc fault_resume_user rjmp enter_monitor_mode - .section .kprobes.text, "ax", @progbits + section_rng_asmtype(SECTION_TEXT, kprobes, ax, @progbits) .type handle_debug, @function handle_debug: sub sp, 4 /* r12_orig */
@@ -826,7 +827,7 @@ irq_level\level: IRQ_LEVEL 2 IRQ_LEVEL 3 - .section .kprobes.text, "ax", @progbits + section_rng_asmtype(SECTION_TEXT, kprobes, ax, @progbits) .type enter_monitor_mode, @function enter_monitor_mode: /*
arch/avr32/kernel/vmlinux.lds.S +0 -1
@@ -49,7 +49,6 @@ SECTIONS _stext = .; *(.ex.text) *(.irq.text) - KPROBES_TEXT TEXT_TEXT SCHED_TEXT LOCK_TEXT
arch/blackfin/kernel/vmlinux.lds.S +0 -1
@@ -36,7 +36,6 @@ SECTIONS LOCK_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT - KPROBES_TEXT #ifdef CONFIG_ROMKERNEL __sinittext = .; INIT_TEXT
arch/c6x/kernel/vmlinux.lds.S +0 -1
@@ -73,7 +73,6 @@ SECTIONS LOCK_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT - KPROBES_TEXT *(.fixup) *(.gnu.warning) }
arch/hexagon/kernel/vmlinux.lds.S +0 -1
@@ -51,7 +51,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT *(.fixup) } _etext = .;
arch/ia64/kernel/jprobes.S +2 -1
@@ -46,11 +46,12 @@ */ #include <asm/asmmacro.h> #include <asm/break.h> +#include <asm/ranges.h> /* * void jprobe_break(void) */ - .section .kprobes.text, "ax" + section_rng(SECTION_TEXT, kprobes, ax) ENTRY(jprobe_break) break.m __IA64_BREAK_JPROBE END(jprobe_break)
arch/ia64/kernel/vmlinux.lds.S +0 -1
@@ -47,7 +47,6 @@ SECTIONS { TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT *(.gnu.linkonce.t*) }
arch/ia64/lib/flush.S +3 -2
@@ -8,6 +8,7 @@ */ #include <asm/asmmacro.h> +#include <asm/ranges.h> /*
@@ -20,7 +21,7 @@ * * Note: "in0" and "in1" are preserved for debugging purposes. */ - .section .kprobes.text,"ax" + section_rng(SECTION_TEXT, kprobes, ax) GLOBAL_ENTRY(flush_icache_range) .prologue
@@ -72,7 +73,7 @@ END(flush_icache_range) * * Note: "in0" and "in1" are preserved for debugging purposes. */ - .section .kprobes.text,"ax" + section_rng(SECTION_TEXT, kprobes, ax) GLOBAL_ENTRY(clflush_cache_range) .prologue
arch/metag/kernel/vmlinux.lds.S +0 -1
@@ -22,7 +22,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.text.*)
arch/microblaze/kernel/vmlinux.lds.S +0 -1
@@ -34,7 +34,6 @@ SECTIONS { EXIT_CALL SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT . = ALIGN (4) ;
arch/mips/kernel/vmlinux.lds.S +0 -1
@@ -56,7 +56,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.text.*)
arch/mn10300/kernel/vmlinux.lds.S +0 -1
@@ -31,7 +31,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT *(.fixup) *(.gnu.warning) } = 0xcb
arch/nios2/kernel/vmlinux.lds.S +0 -1
@@ -40,7 +40,6 @@ SECTIONS LOCK_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT - KPROBES_TEXT } =0 _etext = .;
arch/openrisc/kernel/vmlinux.lds.S +0 -1
@@ -48,7 +48,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.fixup)
arch/parisc/kernel/vmlinux.lds.S +0 -1
@@ -70,7 +70,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.text.do_softirq)
arch/powerpc/include/asm/ppc_asm.h +4 -3
@@ -9,6 +9,7 @@#include <asm/processor.h> #include <asm/ppc-opcode.h> #include <asm/firmware.h> +#include <asm/ranges.h> #ifndef __ASSEMBLY__#error __FILE__ should only be used in assembler files
@@ -218,7 +219,7 @@ name: \ .localentry name,.-name#define _KPROBE (name) \ - .section ".kprobes.text","a"; \ + section_rng(SECTION_TEXT, kprobes, a); \ .align 2 ; \ .type name,@function; \ .globl name; \
@@ -248,7 +249,7 @@ GLUE(.,name):#define _GLOBAL_TOC (name) _GLOBAL(name)#define _KPROBE (name) \ - .section ".kprobes.text","a"; \ + section_rng(SECTION_TEXT, kprobes, a); \ .align 2 ; \ .globl name; \ .globl GLUE(.,name); \
@@ -280,7 +281,7 @@ n:#define _GLOBAL_TOC (name) _GLOBAL(name)#define _KPROBE (n) \ - .section ".kprobes.text","a"; \ + section_rng(SECTION_TEXT, kprobes, a); \ .globl n; \ n:
arch/powerpc/kernel/vmlinux.lds.S +0 -1
@@ -53,7 +53,6 @@ SECTIONS *(.text .fixup __ftr_alt_* .ref.text) SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT
arch/s390/kernel/entry.S +3 -2
@@ -23,6 +23,7 @@ #include <asm/vx-insn.h> #include <asm/setup.h> #include <asm/nmi.h> +#include <asm/ranges.h> __PT_R0 = __PT_GPRS __PT_R1 = __PT_GPRS + 8
@@ -162,7 +163,7 @@ _PIF_WORK = (_PIF_PER_TRAP) tm off+\addr, \mask .endm - .section .kprobes.text, "ax" + section_rng(SECTION_TEXT, kprobes, ax) .Ldummy: /* * This nop exists only in order to avoid that __switch_to starts at
@@ -975,7 +976,7 @@ ENTRY(restart_int_handler) brc 2,2b 3: j 3b - .section .kprobes.text, "ax" + section_rng(SECTION_TEXT, kprobes, ax) #ifdef CONFIG_CHECK_STACK /*
arch/s390/kernel/kprobes.c +3 -3
@@ -287,9 +287,9 @@ static void kprobe_reenter_check(struct kprobe_ctlblk *kcb, struct kprobe *p)case KPROBE_REENTER :default :/* -* A kprobe on the code path to single step an instruction -* is a BUG. The code path resides in the .kprobes.text -* section and is executed with interrupts disabled. +* A kprobe on the code path to single step an instruction is a +* BUG. The code path resides in the kprobes section range and +* is executed with interrupts disabled. */ printk (KERN_EMERG "Invalid kprobe detected at %p.\n" , p->addr);dump_kprobe (p);
arch/s390/kernel/mcount.S +1 -1
@@ -10,7 +10,7 @@ #include <asm/ftrace.h> #include <asm/ptrace.h> - .section .kprobes.text, "ax" + section_rng(SECTION_TEXT, kprobes, ax,) ENTRY(ftrace_stub) br %r14
arch/s390/kernel/vmlinux.lds.S +0 -1
@@ -36,7 +36,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.fixup)
arch/score/kernel/vmlinux.lds.S +0 -1
@@ -41,7 +41,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT *(.text.*) *(.fixup) . = ALIGN (4) ;
arch/sh/kernel/vmlinux.lds.S +0 -1
@@ -37,7 +37,6 @@ SECTIONS EXTRA_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.fixup)
arch/sparc/kernel/vmlinux.lds.S +0 -1
@@ -50,7 +50,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT *(.gnu.warning)
arch/sparc/mm/ultra.S +2 -1
@@ -16,6 +16,7 @@ #include <asm/cacheflush.h> #include <asm/hypervisor.h> #include <asm/cpudata.h> +#include <asm/ranges.h> /* Basically, most of the Spitfire vs. Cheetah madness * has to do with the fact that Cheetah does not support
@@ -148,7 +149,7 @@ __spitfire_flush_tlb_mm_slow: /* * The following code flushes one page_size worth. */ - .section .kprobes.text, "ax" + section_rng(SECTION_TEXT, kprobes, ax) .align 32 .globl __flush_icache_page __flush_icache_page: /* %o0 = phys_page */
arch/tile/kernel/vmlinux.lds.S +0 -1
@@ -43,7 +43,6 @@ SECTIONS HEAD_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT __fix_text_end = .; /* tile-cpack won't rearrange before this */
arch/x86/kernel/kprobes/core.c +5 -6
@@ -579,9 +579,9 @@ static int reenter_kprobe(struct kprobe *p, struct pt_regs *regs,case KPROBE_REENTER :/* A probe has been hit in the codepath leading up to, or just * after, single-stepping of a probed instruction. This entire -* codepath should strictly reside in .kprobes.text section. -* Raise a BUG or we'll continue in an endless reentering loop -* and eventually a stack overflow. +* codepath should strictly reside in the kprobes section +* range. Raise a BUG or we'll continue in an endless +* reentering loop and eventually a stack overflow. */ printk (KERN_WARNING "Unrecoverable kprobe detected at %p.\n" , p->addr);
@@ -1128,10 +1128,9 @@ NOKPROBE_SYMBOL(longjmp_break_handler);bool arch_within_kprobe_blacklist (unsigned long addr) { -return (addr >= (unsigned long )__kprobes_text_start && - addr < (unsigned long )__kprobes_text_end) || +return (SECTION_ADDR_IN_RANGE (kprobes, addr) || (addr >= (unsigned long )__entry_text_start && - addr < (unsigned long )__entry_text_end); + addr < (unsigned long )__entry_text_end)); }int __init arch_init_kprobes (void )
arch/x86/kernel/vmlinux.lds.S +0 -1
@@ -98,7 +98,6 @@ SECTIONS TEXT_TEXT SCHED_TEXT LOCK_TEXT - KPROBES_TEXT ENTRY_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT
include/asm-generic/sections.h +0 -2
@@ -324,7 +324,6 @@* Following global variables are optional and may be unavailable on some * architectures and/or kernel configurations. * _text, _data -* __kprobes_text_start, __kprobes_text_end * __entry_text_start, __entry_text_end * __ctors_start, __ctors_end */
@@ -335,7 +334,6 @@ extern char __init_begin[], __init_end[];extern char _sinittext[], _einittext[];extern char _end[];extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[]; -extern char __kprobes_text_start[], __kprobes_text_end[];extern char __entry_text_start[], __entry_text_end[];extern char __start_rodata[], __end_rodata[];
include/asm-generic/vmlinux.lds.h +0 -6
@@ -444,12 +444,6 @@ *(.spinlock.text) \ VMLINUX_SYMBOL(__lock_text_end) = .; -#define KPROBES_TEXT \ - ALIGN_FUNCTION(); \ - VMLINUX_SYMBOL(__kprobes_text_start) = .; \ - *(.kprobes.text) \ - VMLINUX_SYMBOL(__kprobes_text_end) = .; -#define ENTRY_TEXT \ ALIGN_FUNCTION(); \ VMLINUX_SYMBOL(__entry_text_start) = .; \
include/linux/compiler.h +1 -1
@@ -544,7 +544,7 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s/* Ignore/forbid kprobes attach on very low level functions marked by this attribute: */ #ifdef CONFIG_KPROBES -# define __kprobes __attribute__((__section__(".kprobes.text"))) +# define __kprobes __LINUX_RANGE(SECTION_TEXT, kprobes)# define nokprobe_inline __always_inline#else # define __kprobes
include/linux/kprobes.h +3 -0
@@ -42,8 +42,11 @@#include <linux/ftrace.h> #ifdef CONFIG_KPROBES +#include <linux/ranges.h> #include <asm/kprobes.h> +DECLARE_SECTION_RANGE (kprobes); +/* kprobe_status settings */ #define KPROBE_HIT_ACTIVE 0x00000001#define KPROBE_HIT_SS 0x00000002
kernel/kprobes.c +4 -2
@@ -1328,8 +1328,7 @@ out:bool __weak arch_within_kprobe_blacklist (unsigned long addr) {/* The __kprobes marked functions and entry code must not be probed */ -return addr >= (unsigned long )__kprobes_text_start && - addr < (unsigned long )__kprobes_text_end; +return SECTION_ADDR_IN_RANGE (kprobes, addr); }bool within_kprobe_blacklist (unsigned long addr)
@@ -2129,6 +2128,9 @@ static struct notifier_block kprobe_module_nb = {extern unsigned long __start_kprobe_blacklist[];extern unsigned long __stop_kprobe_blacklist[]; +/* Actual kprobes section range */ +DEFINE_SECTION_RANGE (kprobes,SECTION_TEXT ); +static int __init init_kprobes (void ) {int i, err =0 ;
scripts/Makefile +1 -0
@@ -10,6 +10,7 @@ # check-lc_ctype: Used in Documentation/DocBook HOST_EXTRACFLAGS += -I$(srctree)/tools/include +HOST_EXTRACFLAGS += -U__KERNEL__ hostprogs-$(CONFIG_KALLSYMS) += kallsyms hostprogs-$(CONFIG_LOGO) += pnmtologo
scripts/mod/Makefile +2 -0
@@ -1,5 +1,7 @@ OBJECT_FILES_NON_STANDARD := y +HOST_EXTRACFLAGS += -U__KERNEL__ + hostprogs-y := modpost mk_elfconfig always := $(hostprogs-y) empty.o
scripts/mod/modpost.c +7 -1
@@ -19,10 +19,16 @@#include <stdbool.h> #include <errno.h> #include "modpost.h" +#include "../../include/generated/autoconf.h" #include "../../include/linux/license.h" #include "../../include/linux/export.h" +#include "../../include/linux/sections.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/linux/ranges.h" +#include "../../include/asm-generic/ranges.h" +/* Are we using CONFIG_MODVERSIONS? */ static int modversions =0 ;/* Warn about undefined symbols? (do so if we have vmlinux) */
@@ -888,7 +894,7 @@ static void check_section(const char *modname, struct elf_info *elf,#define DATA_SECTIONS ".data", ".data.rel"#define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \ - ".kprobes.text" + SECTION_RNG(SECTION_TEXT, kprobes)#define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \ ".fixup", ".entry.text", ".exception.text", ".text.*", \ ".coldtext"
scripts/recordmcount.c +6 -1
@@ -33,6 +33,11 @@#include <string.h> #include <unistd.h> +#include "../../include/linux/sections.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/linux/ranges.h" +#include "../../include/asm-generic/ranges.h" +#ifndef EM_METAG /* Remove this when these make it to the standard system elf.h. */ #define EM_METAG 174
@@ -356,7 +361,7 @@ is_mcounted_section_name(char const *const txtname)strcmp (".sched.text" , txtname) ==0 ||strcmp (".spinlock.text" , txtname) ==0 ||strcmp (".irqentry.text" , txtname) ==0 || -strcmp (".kprobes.text" , txtname) ==0 || +strcmp (SECTION_RNG (SECTION_TEXT , kprobe), txtname) ==0 ||strcmp (".text.unlikely" , txtname) ==0 ; }
scripts/recordmcount.pl +1 -1
@@ -134,7 +134,7 @@ my %text_sections = ( ".sched.text" => 1, ".spinlock.text" => 1, ".irqentry.text" => 1, - ".kprobes.text" => 1, + ".text.rng.kprobes.any" => 1, ".text.unlikely" => 1, );
Signature · 1 line
2.8.4
Masami Hiramatsu
maintainerRe: [RFC v3 12/13] kprobes: port .kprobes.text to section range
Quoted 52 lines · On Fri, 22 Jul 2016 14:24:46 -0700 "Luis R. Rodriguez" <[email protected]>…
kprobe makes use of two custom sections, each custom section is folded into one of the standard Linux sections types as follows, it currently relies on the linker script to fold the custom section onto the respective Linux section:
type Linux-section custom section name begin end table .init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist range .text .kprobes.text __kprobes_text_start __kprobes_text_endThis ports the .kprobes.text custom section to the standard Linux ranges API allowing us remove all the custom kprobe section declarations from the linker script.
Tested with
CONFIG_KPROBES_SANITY_TEST, it passes with:Kprobe smoke test: started
Kprobe smoke test: passed successfullyThen tested
CONFIG_SAMPLE_KPROBESondo_fork, and the kprobe bites and kicks as expected.Also ran ./ftracetest with no issues:
$ sudo ./ftracetest === Ftrace unit tests === [1] Basic trace file check [PASS] [2] Basic test for tracers [PASS] [3] Basic trace clock test [PASS] [4] Basic event tracing check [PASS] [5] event tracing - enable/disable with event level files [PASS] [6] event tracing - restricts events based on pid [PASS] [7] event tracing - enable/disable with subsystem level files [PASS] [8] event tracing - enable/disable with top level files [PASS] [9] ftrace - function graph filters with stack tracer [PASS] [10] ftrace - function graph filters [PASS] [11] ftrace - function profiler with function tracing [PASS] [12] Test creation and deletion of trace instances while setting an event[PASS] [13] Test creation and deletion of trace instances [PASS] [14] Kprobe dynamic event - adding and removing [PASS] [15] Kprobe dynamic event - busy event check [PASS] [16] Kprobe dynamic event with arguments [PASS] [17] Kprobe dynamic event with function tracer [PASS] [18] Kretprobe dynamic event with arguments [PASS] [19] event trigger - test event enable/disable trigger [PASS] [20] event trigger - test trigger filter [PASS] [21] event trigger - test histogram modifiers [PASS] [22] event trigger - test histogram trigger [PASS] [23] event trigger - test multiple histogram triggers [PASS] [24] event trigger - test snapshot-trigger [PASS] [25] event trigger - test stacktrace-trigger [PASS] [26] event trigger - test traceon/off trigger [PASS]
Quoted 7 lines
# of passed: 26 # of failed: 0 # of unresolved: 0 # of untested: 0 # of unsupported: 0 # of xfailed: 0 # of undefined(test bug): 0
Looks good to me except for the modpost part.
scripts/Makefile line 13
Quoted 10 lines
scripts/Makefile +1
-0@@ -10,6 +10,7 @@ # check-lc_ctype: Used in Documentation/DocBook HOST_EXTRACFLAGS += -I$(srctree)/tools/include +HOST_EXTRACFLAGS += -U__KERNEL__
This looks a add-hoc hack. If we just need SECTION_RNG(SECTION_TEXT, kprobes) to convert to section name, can we export the definitions outside of _KERNEL_ ?
Thank you,
Quoted 86 lines
scripts/Makefile +0
-0hostprogs-$(CONFIG_KALLSYMS) += kallsyms hostprogs-$(CONFIG_LOGO) += pnmtologoscripts/mod/Makefile +2
-0@@ -1,5 +1,7 @@ OBJECT_FILES_NON_STANDARD := y +HOST_EXTRACFLAGS += -U__KERNEL__ + hostprogs-y := modpost mk_elfconfig always := $(hostprogs-y) empty.oscripts/mod/modpost.c +7
-1@@ -19,10 +19,16 @@#include <stdbool.h> #include <errno.h> #include "modpost.h" +#include "../../include/generated/autoconf.h" #include "../../include/linux/license.h" #include "../../include/linux/export.h" +#include "../../include/linux/sections.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/linux/ranges.h" +#include "../../include/asm-generic/ranges.h" +/* Are we using CONFIG_MODVERSIONS? */ static int modversions =0 ;/* Warn about undefined symbols? (do so if we have vmlinux) */ @@ -888,7 +894,7 @@ static void check_section(const char *modname, struct elf_info *elf,#define DATA_SECTIONS ".data", ".data.rel"#define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \ - ".kprobes.text" + SECTION_RNG(SECTION_TEXT, kprobes)#define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \ ".fixup", ".entry.text", ".exception.text", ".text.*", \ ".coldtext"scripts/recordmcount.c +6
-1@@ -33,6 +33,11 @@#include <string.h> #include <unistd.h> +#include "../../include/linux/sections.h" +#include "../../include/asm-generic/sections.h" +#include "../../include/linux/ranges.h" +#include "../../include/asm-generic/ranges.h" +#ifndef EM_METAG /* Remove this when these make it to the standard system elf.h. */ #define EM_METAG 174@@ -356,7 +361,7 @@ is_mcounted_section_name(char const *const txtname)strcmp (".sched.text" , txtname) ==0 ||strcmp (".spinlock.text" , txtname) ==0 ||strcmp (".irqentry.text" , txtname) ==0 || -strcmp (".kprobes.text" , txtname) ==0 || +strcmp (SECTION_RNG (SECTION_TEXT , kprobe), txtname) ==0 ||strcmp (".text.unlikely" , txtname) ==0 ; }scripts/recordmcount.pl +1
-1@@ -134,7 +134,7 @@ my %text_sections = ( ".sched.text" => 1, ".spinlock.text" => 1, ".irqentry.text" => 1, - ".kprobes.text" => 1, + ".text.rng.kprobes.any" => 1, ".text.unlikely" => 1, );Signature · 1 line
2.8.4
Signature · 1 line
Masami Hiramatsu <[email protected]>
Luis R. Rodriguez
maintainerRe: [RFC v3 12/13] kprobes: port .kprobes.text to section range
Quoted 63 lines · Masami Hiramatsu
Quoted 52 lines · On Fri, 22 Jul 2016 14:24:46 -0700 "Luis R. Rodriguez" <[email protected]>…
kprobe makes use of two custom sections, each custom section is folded into one of the standard Linux sections types as follows, it currently relies on the linker script to fold the custom section onto the respective Linux section:
type Linux-section custom section name begin end table .init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist range .text .kprobes.text __kprobes_text_start __kprobes_text_endThis ports the .kprobes.text custom section to the standard Linux ranges API allowing us remove all the custom kprobe section declarations from the linker script.
Tested with
CONFIG_KPROBES_SANITY_TEST, it passes with:Kprobe smoke test: started
Kprobe smoke test: passed successfullyThen tested
CONFIG_SAMPLE_KPROBESondo_fork, and the kprobe bites and kicks as expected.Also ran ./ftracetest with no issues:
$ sudo ./ftracetest === Ftrace unit tests === [1] Basic trace file check [PASS] [2] Basic test for tracers [PASS] [3] Basic trace clock test [PASS] [4] Basic event tracing check [PASS] [5] event tracing - enable/disable with event level files [PASS] [6] event tracing - restricts events based on pid [PASS] [7] event tracing - enable/disable with subsystem level files [PASS] [8] event tracing - enable/disable with top level files [PASS] [9] ftrace - function graph filters with stack tracer [PASS] [10] ftrace - function graph filters [PASS] [11] ftrace - function profiler with function tracing [PASS] [12] Test creation and deletion of trace instances while setting an event[PASS] [13] Test creation and deletion of trace instances [PASS] [14] Kprobe dynamic event - adding and removing [PASS] [15] Kprobe dynamic event - busy event check [PASS] [16] Kprobe dynamic event with arguments [PASS] [17] Kprobe dynamic event with function tracer [PASS] [18] Kretprobe dynamic event with arguments [PASS] [19] event trigger - test event enable/disable trigger [PASS] [20] event trigger - test trigger filter [PASS] [21] event trigger - test histogram modifiers [PASS] [22] event trigger - test histogram trigger [PASS] [23] event trigger - test multiple histogram triggers [PASS] [24] event trigger - test snapshot-trigger [PASS] [25] event trigger - test stacktrace-trigger [PASS] [26] event trigger - test traceon/off trigger [PASS]Quoted 7 lines
# of passed: 26 # of failed: 0 # of unresolved: 0 # of untested: 0 # of unsupported: 0 # of xfailed: 0 # of undefined(test bug): 0
Quoted 1 line
Looks good to me except for the modpost part.
OK thanks!
Quoted 7 lines
Quoted 7 lines
scripts/Makefile +0
-0@@ -10,6 +10,7 @@ # check-lc_ctype: Used in Documentation/DocBook
Quoted 5 lines
scripts/Makefile line 13
Quoted 2 lines
scripts/Makefile +1
-0HOST_EXTRACFLAGS += -I$(srctree)/tools/include +HOST_EXTRACFLAGS += -U__KERNEL__This looks a add-hoc hack. If we just need
SECTION_RNG(SECTION_TEXT, kprobes)to convert to section name, can we export the definitions outside of _KERNEL_ ?
We can, it was just a matter of deciding if we were OK with open coding the section, copying over some defines, or sharing somehow (this was one way) the header files.
Josh seems to prefer to open coding out the names on the tools we can certanly do that here as well, I think his point that the names should/will likely never change is sufficient motivation to avoid all this and prefer open coding this.
Will do that in the next spin unless I hear otherwise.
Luis
Luis R. Rodriguez
maintainerRFC v3 13/13 kprobes: port blacklist kprobes to linker table
In reply to Luis R. Rodriguezkprobe makes use of two sections, the one dealing with the actual kprobes was recently ported using the standard section range API. The blacklist functionality of kprobes is still using a custom section and declaring its custom section using the linker script as follows:
type Linux-section custom section name begin end
table .init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist
This ports the _kprobe_blacklist custom section to the standard Linux linker table API allowing us remove all the custom blacklist kprobe section declarations from the linker script.
This has been tested by trying to register a kprobe on a blacklisted symbol (these are declared with NOKPROBE_SYMBOL()), and confirms that this fails to work as expected. This was tested with:
# insmod samples/kprobes/kprobe_example.ko symbol="get_kprobe"
This fails to load as expected with:
insmod: ERROR: could not insert module samples/kprobes/kprobe_example.ko: Invalid parameters
v3: this patch was introduced in this series
--- include/asm-generic/vmlinux.lds.h | 10 ---------- include/linux/kprobes.h | 5 +++-- kernel/kprobes.c | 11 ++++------- 3 files changed, 7 insertions(+), 19 deletions(-)
include/asm-generic/vmlinux.lds.h +0 -10
@@ -113,15 +113,6 @@#define BRANCH_PROFILE ()#endif -#ifdef CONFIG_KPROBES -#define KPROBE_BLACKLIST () . = ALIGN(8); \ - VMLINUX_SYMBOL(__start_kprobe_blacklist) = .; \ - *(_kprobe_blacklist) \ - VMLINUX_SYMBOL(__stop_kprobe_blacklist) = .; -#else -#define KPROBE_BLACKLIST () -#endif -#ifdef CONFIG_EVENT_TRACING #define FTRACE_EVENTS () . = ALIGN(8); \ VMLINUX_SYMBOL(__start_ftrace_events) = .; \
@@ -519,7 +510,6 @@ *(SECTION_INIT_RODATA ) \ FTRACE_EVENTS() \ TRACE_SYSCALLS() \ - KPROBE_BLACKLIST() \ MEM_DISCARD(init.rodata) \ CLK_OF_TABLES() \RESERVEDMEM_OF_TABLES () \
include/linux/kprobes.h +3 -2
@@ -43,9 +43,11 @@#ifdef CONFIG_KPROBES #include <linux/ranges.h> +#include <linux/tables.h> #include <asm/kprobes.h> DECLARE_SECTION_RANGE (kprobes); +DECLARE_LINKTABLE(unsigned long, _kprobe_blacklist);/* kprobe_status settings */ #define KPROBE_HIT_ACTIVE 0x00000001
@@ -490,8 +492,7 @@ static inline int enable_jprobe(struct jprobe *jp)* by using this macro. */ #define __NOKPROBE_SYMBOL (fname) \ -static unsigned long __used \ - __attribute__((section("_kprobe_blacklist"))) \ +static LINKTABLE_INIT_DATA(_kprobe_blacklist, all) \ _kbl_addr_##fname = (unsigned long)fname;#define NOKPROBE_SYMBOL (fname) __NOKPROBE_SYMBOL(fname)#else
kernel/kprobes.c +4 -7
@@ -2053,14 +2053,13 @@ NOKPROBE_SYMBOL(dump_kprobe);* since a kprobe need not necessarily be at the beginning * of a function. */ -static int __init populate_kprobe_blacklist (unsigned long *start, -unsigned long *end) +static int __init populate_kprobe_blacklist (void ) {unsigned long *iter;struct kprobe_blacklist_entry *ent;unsigned long entry, offset =0 , size =0 ; -for (iter = start; iter < end; iter++) { + LINKTABLE_FOR_EACH(iter, _kprobe_blacklist) { entry =arch_deref_entry_point ((void *)*iter); if (!kernel_text_address(entry) ||
@@ -2125,8 +2124,7 @@ static struct notifier_block kprobe_module_nb = { };/* Markers of _kprobe_blacklist section */ -extern unsigned long __start_kprobe_blacklist[]; -extern unsigned long __stop_kprobe_blacklist[]; +DEFINE_LINKTABLE_INIT_DATA(unsigned long, _kprobe_blacklist);/* Actual kprobes section range */ DEFINE_SECTION_RANGE (kprobes,SECTION_TEXT );
@@ -2143,8 +2141,7 @@ static int __init init_kprobes(void)raw_spin_lock_init (&(kretprobe_table_locks[i].lock)); } - err =populate_kprobe_blacklist (__start_kprobe_blacklist, - __stop_kprobe_blacklist); + err =populate_kprobe_blacklist ();if (err) {pr_err ("kprobes: failed to populate blacklist: %d\n" , err);pr_err ("Please take care of using kprobes.\n" );
Signature · 1 line
2.8.4
Re: [RFC v3 13/13] kprobes: port blacklist kprobes to linker table
Quoted 9 lines · On Fri, 22 Jul 2016 14:24:47 -0700 "Luis R. Rodriguez" <[email protected]>…
kprobe makes use of two sections, the one dealing with the actual kprobes was recently ported using the standard section range API. The blacklist functionality of kprobes is still using a custom section and declaring its custom section using the linker script as follows:
type Linux-section custom section name begin end
table .init.data_kprobe_blacklist__start_kprobe_blacklist__stop_kprobe_blacklist
Quoted 7 lines
This ports the
_kprobe_blacklistcustom section to the standard Linux linker table API allowing us remove all the custom blacklist kprobe section declarations from the linker script.This has been tested by trying to register a kprobe on a blacklisted symbol (these are declared with
NOKPROBE_SYMBOL()), and confirms that this fails to work as expected. This was tested with:
This is OK for me, and if you would like to make sure, please use ftrace to probe
(easier than making new module) and compare debugfs/blacklist which shows
all blacklisted functions, so if all the function names are same it must be OK :).
Thank you,
Quoted 114 lines
# insmod samples/kprobes/kprobe_example.ko symbol="get_kprobe"This fails to load as expected with:
insmod: ERROR: could not insert module
samples/kprobes/kprobe_example.ko: Invalid parametersv3: this patch was introduced in this series
Signed-off-by Luis R. Rodriguez <[email protected]>--- include/asm-generic/vmlinux.lds.h | 10 ---------- include/linux/kprobes.h | 5 +++-- kernel/kprobes.c | 11 ++++------- 3 files changed, 7 insertions(+), 19 deletions(-)include/asm-generic/vmlinux.lds.h +0
-10@@ -113,15 +113,6 @@#define BRANCH_PROFILE ()#endif -#ifdef CONFIG_KPROBES -#define KPROBE_BLACKLIST () . = ALIGN(8); \ - VMLINUX_SYMBOL(__start_kprobe_blacklist) = .; \ - *(_kprobe_blacklist) \ - VMLINUX_SYMBOL(__stop_kprobe_blacklist) = .; -#else -#define KPROBE_BLACKLIST () -#endif -#ifdef CONFIG_EVENT_TRACING #define FTRACE_EVENTS () . = ALIGN(8); \ VMLINUX_SYMBOL(__start_ftrace_events) = .; \@@ -519,7 +510,6 @@ *(SECTION_INIT_RODATA ) \ FTRACE_EVENTS() \ TRACE_SYSCALLS() \ - KPROBE_BLACKLIST() \ MEM_DISCARD(init.rodata) \ CLK_OF_TABLES() \RESERVEDMEM_OF_TABLES () \include/linux/kprobes.h +3
-2@@ -43,9 +43,11 @@#ifdef CONFIG_KPROBES #include <linux/ranges.h> +#include <linux/tables.h> #include <asm/kprobes.h> DECLARE_SECTION_RANGE (kprobes); +DECLARE_LINKTABLE(unsigned long, _kprobe_blacklist);/* kprobe_status settings */ #define KPROBE_HIT_ACTIVE 0x00000001@@ -490,8 +492,7 @@ static inline int enable_jprobe(struct jprobe *jp)* by using this macro. */ #define __NOKPROBE_SYMBOL (fname) \ -static unsigned long __used \ - __attribute__((section("_kprobe_blacklist"))) \ +static LINKTABLE_INIT_DATA(_kprobe_blacklist, all) \ _kbl_addr_##fname = (unsigned long)fname;#define NOKPROBE_SYMBOL (fname) __NOKPROBE_SYMBOL(fname)#else kernel/kprobes.c +4
-7@@ -2053,14 +2053,13 @@ NOKPROBE_SYMBOL(dump_kprobe);* since a kprobe need not necessarily be at the beginning * of a function. */ -static int __init populate_kprobe_blacklist (unsigned long *start, -unsigned long *end) +static int __init populate_kprobe_blacklist (void ) {unsigned long *iter;struct kprobe_blacklist_entry *ent;unsigned long entry, offset =0 , size =0 ; -for (iter = start; iter < end; iter++) { + LINKTABLE_FOR_EACH(iter, _kprobe_blacklist) { entry =arch_deref_entry_point ((void *)*iter); if (!kernel_text_address(entry) ||@@ -2125,8 +2124,7 @@ static struct notifier_block kprobe_module_nb = { };/* Markers of _kprobe_blacklist section */ -extern unsigned long __start_kprobe_blacklist[]; -extern unsigned long __stop_kprobe_blacklist[]; +DEFINE_LINKTABLE_INIT_DATA(unsigned long, _kprobe_blacklist);/* Actual kprobes section range */ DEFINE_SECTION_RANGE (kprobes,SECTION_TEXT );@@ -2143,8 +2141,7 @@ static int __init init_kprobes(void)raw_spin_lock_init (&(kretprobe_table_locks[i].lock)); } - err =populate_kprobe_blacklist (__start_kprobe_blacklist, - __stop_kprobe_blacklist); + err =populate_kprobe_blacklist ();if (err) {pr_err ("kprobes: failed to populate blacklist: %d\n" , err);pr_err ("Please take care of using kprobes.\n" );Signature · 1 line
2.8.4
Signature · 1 line
Masami Hiramatsu <[email protected]>
Luis R. Rodriguez
maintainerRe: [RFC v3 13/13] kprobes: port blacklist kprobes to linker table
Quoted 16 lines · Masami Hiramatsu
Quoted 13 lines · On Fri, 22 Jul 2016 14:24:47 -0700 "Luis R. Rodriguez" <[email protected]>…
kprobe makes use of two sections, the one dealing with the actual kprobes was recently ported using the standard section range API. The blacklist functionality of kprobes is still using a custom section and declaring its custom section using the linker script as follows:
type Linux-section custom section name begin end
table .init.data_kprobe_blacklist__start_kprobe_blacklist__stop_kprobe_blacklistThis ports the
_kprobe_blacklistcustom section to the standard Linux linker table API allowing us remove all the custom blacklist kprobe section declarations from the linker script.
Quoted 8 lines
Quoted 3 lines
This has been tested by trying to register a kprobe on a blacklisted symbol (these are declared with
NOKPROBE_SYMBOL()), and confirms that this fails to work as expected. This was tested with:This is OK for me, and if you would like to make sure, please use ftrace to probe
(easier than making new module) and compare debugfs/blacklist which shows
all blacklisted functions, so if all the function names are same it must be OK :).
Ah I see, sure thanks for the tip! I was actually hoping to write a unit test that automates this testing, but that can be done and submitted later, the approach you suggest should make writing a unit easier as well.
Quoted 1 line
Acked-by Masami Hiramatsu <[email protected]>
Great, thanks,
Luis
Masami Hiramatsu
maintainerHi Luis,
Quoted 25 lines · On Fri, 22 Jul 2016 14:24:34 -0700 "Luis R. Rodriguez" <[email protected]>…
This RFC v3 builds off the last RFC v2 series [0] for adding linker tables. The largest amount of work here was to take Russell King's feedback on using linker table for kprobes text not being appropriate -- and providing another lightweight API for simple section ranges: read-only stitched pieces of executable code. This required also generalizing common building blocks for both linker tables and section ranges, these building blocks are defined now in
include/linux/sections.handasm-generic/section.h. The other last thing decided was to not support sub-sections. In the hunt for this I could think of anything that really required this, and if it was needed it did not seem impossible to port over to avoid its use. Please let me know if there are valid uses cases for sub-sections.Other significant effort here was to provide a set of common assembly helpers which could be used across architectures, this starts off some of this work for generic helpers which carve out and define custom Linux sections.
Lastly, this now also goes with two ports which required module support when using linker tables: jump labels, and dynamic debug support. A few extensions have been made to the original series in order to provide support for that.
Since kprobes actually had both a linker table and a section range the patch that dealt with kprobes is now split off in two patches, one that deals with its linker table and another for its section ranges.
Quoted 6 lines
More elaborate uses for linker tables are possible, I'll hold off on any of this type of work until at least the basic building blocks are fleshed out. To review how this work came about, and more elaborate uses being evaluated check out the userspace linker-tables mockup solution [1]. Hopefully most of the possible bikeshedding was already dealt with through that tree. Thanks to hpa for tons of feedback.
Great! so table and ranges completely replace the old-style(add-hoc) _kprobe and NOKPROBE_SYMBOL() implementation, good job! :)
Quoted 11 lines
Should you need it, the code here is also available on my linux-next 20160722-linker-table-v3-try2 branch on kernel.org [2]. Lastly, ranges and table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
I'm not a lawyer, so I don't know really it is compatible with GPLv2, and if it is, I'm not sure the reason why we need another license. AFAICS the license terms, most of parts looks reasonable. I just concern clause 8, after fifteen years, is that still GPLv2 compatible? (I'd like see FAQ about this license...)
Thank you!
Quoted 321 lines
This all goes tested by 0-day... however since I found an issue with linker tables and blackfin this series remains as RFC -- I'll try to debug the issue with Steven Miao. The issue with blackfin is using a config that enables
CONFIG_FW_LOADER=yandCONFIG_DYNAMIC_DEBUG=y[5] we end up with the following at final link time:LD
init/built-in.olib/built-in.o: In function `dynamic_debug_init':
lib/dynamic_debug.c:(.init.text+0x156): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x15a): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x160): undefined reference to__verbose' lib/dynamic_debug.c:(.init.text+0x164): undefined reference to__verbose' lib/dynamic_debug.c:(.init.text+0x214): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x218): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x252): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x258): undefined reference to__verbose' lib/dynamic_debug.c:(.init.text+0x25c): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x260): undefined reference to__verbose'drivers/built-in.o: In function `release_firmware':
(.text+0x22dc2): undefined reference to `builtin_fw'drivers/built-in.o: In function `release_firmware':
(.text+0x22dc6): undefined reference tobuiltin_fw__end' drivers/built-in.o: In functionrelease_firmware':
(.text+0x22dca): undefined reference to `builtin_fw'drivers/built-in.o: In function `release_firmware':
(.text+0x22dce): undefined reference tobuiltin_fw__end' drivers/built-in.o: In functionfw_get_builtin_firmware':
drivers/base/firmware_class.c:(.text+0x23008): undefined reference tobuiltin_fw' drivers/base/firmware_class.c:(.text+0x2300c): undefined reference tobuiltin_fw__end' drivers/base/firmware_class.c:(.text+0x23010): undefined reference tobuiltin_fw' drivers/base/firmware_class.c:(.text+0x23014): undefined reference tobuiltin_fw__end' Makefile:957: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1To reproduce then:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
wget http://drvbp1.linux-foundation.org/~mcgrof/2016/07/22/blackfin-fw-dyndbg.config -o .config make.cross ARCH=blackfin[0] https://lkml.kernel.org/r/[email protected]
[1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
[2] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160722-linker-table-v3-try2
[3] https://lkml.kernel.org/r/[email protected]
[4] https://lkml.kernel.org/r/[email protected]
[5] http://drvbp1.linux-foundation.org/~mcgrof/2016/07/22/blackfin-fw-dyndbg.configLuis R. Rodriguez (13):
x86: removeLTO_REFERENCE_INITCALL()
dell-smo8800: includeuaccess.hscripts/module-common.lds: enable generationsections.h: guard against asm and linker scriptsections.h: add sections header to collect all section inforanges.h: add helpers to build and identify Linux section rangestables.h: add linker table support
firmware/Makefile: force recompilation if makefile changes
firmware: port built-in section to linker table
jump_label: port__jump_tableto linker tables
dynamic_debug: port to use linker tables
kprobes: port .kprobes.text to section range
kprobes: port blacklist kprobes to linker table.gitignore | 2 + Documentation/DocBook/Makefile | 3 +- Documentation/DocBook/linker-tables.tmpl | 166 ++++++ Documentation/DocBook/sections.tmpl | 112 ++++ Documentation/kbuild/makefiles.txt | 19 + Makefile | 6 +- arch/alpha/include/asm/ranges.h | 6 + arch/alpha/include/asm/sections.h | 6 + arch/alpha/include/asm/tables.h | 6 + arch/arc/include/asm/ranges.h | 6 + arch/arc/include/asm/tables.h | 6 + arch/arc/kernel/vmlinux.lds.S | 1 - arch/arm/include/asm/jump_label.h | 6 +- arch/arm/include/asm/ranges.h | 6 + arch/arm/include/asm/sections.h | 2 + arch/arm/include/asm/tables.h | 6 + arch/arm/kernel/entry-armv.S | 3 +- arch/arm/kernel/vmlinux-xip.lds.S | 1 - arch/arm/kernel/vmlinux.lds.S | 1 - arch/arm64/include/asm/jump_label.h | 6 +- arch/arm64/include/asm/ranges.h | 6 + arch/arm64/include/asm/sections.h | 6 + arch/arm64/include/asm/tables.h | 6 + arch/avr32/include/asm/ranges.h | 6 + arch/avr32/include/asm/sections.h | 6 + arch/avr32/include/asm/tables.h | 6 + arch/avr32/kernel/entry-avr32b.S | 5 +- arch/avr32/kernel/vmlinux.lds.S | 1 - arch/blackfin/include/asm/ranges.h | 6 + arch/blackfin/include/asm/sections.h | 4 + arch/blackfin/include/asm/tables.h | 6 + arch/blackfin/kernel/vmlinux.lds.S | 1 - arch/c6x/include/asm/ranges.h | 6 + arch/c6x/include/asm/tables.h | 6 + arch/c6x/kernel/vmlinux.lds.S | 1 - arch/cris/include/asm/ranges.h | 6 + arch/cris/include/asm/sections.h | 6 + arch/cris/include/asm/tables.h | 6 + arch/frv/include/asm/ranges.h | 6 + arch/frv/include/asm/tables.h | 6 + arch/h8300/include/asm/ranges.h | 6 + arch/h8300/include/asm/sections.h | 6 + arch/h8300/include/asm/tables.h | 6 + arch/hexagon/include/asm/ranges.h | 6 + arch/hexagon/include/asm/sections.h | 6 + arch/hexagon/include/asm/tables.h | 6 + arch/hexagon/kernel/vmlinux.lds.S | 1 - arch/ia64/include/asm/ranges.h | 6 + arch/ia64/include/asm/sections.h | 7 +- arch/ia64/include/asm/tables.h | 6 + arch/ia64/kernel/jprobes.S | 3 +- arch/ia64/kernel/vmlinux.lds.S | 1 - arch/ia64/lib/flush.S | 5 +- arch/m32r/include/asm/ranges.h | 6 + arch/m32r/include/asm/sections.h | 6 + arch/m32r/include/asm/tables.h | 6 + arch/m68k/include/asm/ranges.h | 6 + arch/m68k/include/asm/sections.h | 6 + arch/m68k/include/asm/tables.h | 6 + arch/metag/include/asm/ranges.h | 6 + arch/metag/include/asm/sections.h | 6 + arch/metag/include/asm/tables.h | 6 + arch/metag/kernel/vmlinux.lds.S | 1 - arch/microblaze/include/asm/ranges.h | 6 + arch/microblaze/include/asm/tables.h | 6 + arch/microblaze/kernel/vmlinux.lds.S | 1 - arch/mips/include/asm/jump_label.h | 6 +- arch/mips/include/asm/ranges.h | 6 + arch/mips/include/asm/sections.h | 6 + arch/mips/include/asm/tables.h | 6 + arch/mips/kernel/vmlinux.lds.S | 1 - arch/mn10300/include/asm/ranges.h | 6 + arch/mn10300/include/asm/sections.h | 6 + arch/mn10300/include/asm/tables.h | 6 + arch/mn10300/kernel/vmlinux.lds.S | 1 - arch/nios2/include/asm/ranges.h | 6 + arch/nios2/include/asm/sections.h | 6 + arch/nios2/include/asm/tables.h | 6 + arch/nios2/kernel/vmlinux.lds.S | 1 - arch/openrisc/include/asm/ranges.h | 6 + arch/openrisc/include/asm/sections.h | 6 + arch/openrisc/include/asm/tables.h | 6 + arch/openrisc/kernel/vmlinux.lds.S | 1 - arch/parisc/include/asm/ranges.h | 6 + arch/parisc/include/asm/tables.h | 6 + arch/parisc/kernel/vmlinux.lds.S | 1 - arch/powerpc/include/asm/jump_label.h | 8 +- arch/powerpc/include/asm/ppc_asm.h | 7 +- arch/powerpc/include/asm/ranges.h | 6 + arch/powerpc/include/asm/sections.h | 11 +- arch/powerpc/include/asm/tables.h | 6 + arch/powerpc/kernel/vmlinux.lds.S | 1 - arch/s390/include/asm/jump_label.h | 6 +- arch/s390/include/asm/ranges.h | 6 + arch/s390/include/asm/tables.h | 6 + arch/s390/kernel/entry.S | 5 +- arch/s390/kernel/kprobes.c | 6 +- arch/s390/kernel/mcount.S | 2 +- arch/s390/kernel/vmlinux.lds.S | 1 - arch/score/include/asm/ranges.h | 6 + arch/score/include/asm/sections.h | 6 + arch/score/include/asm/tables.h | 6 + arch/score/kernel/vmlinux.lds.S | 1 - arch/sh/include/asm/ranges.h | 6 + arch/sh/include/asm/sections.h | 2 + arch/sh/include/asm/tables.h | 6 + arch/sh/kernel/vmlinux.lds.S | 1 - arch/sparc/include/asm/jump_label.h | 6 +- arch/sparc/include/asm/ranges.h | 6 + arch/sparc/include/asm/sections.h | 4 + arch/sparc/include/asm/tables.h | 6 + arch/sparc/kernel/vmlinux.lds.S | 1 - arch/sparc/mm/ultra.S | 3 +- arch/tile/include/asm/ranges.h | 6 + arch/tile/include/asm/sections.h | 4 + arch/tile/include/asm/tables.h | 6 + arch/tile/kernel/vmlinux.lds.S | 1 - arch/um/include/asm/ranges.h | 6 + arch/um/include/asm/tables.h | 6 + arch/unicore32/include/asm/ranges.h | 6 + arch/unicore32/include/asm/sections.h | 6 + arch/unicore32/include/asm/tables.h | 6 + arch/x86/include/asm/jump_label.h | 10 +- arch/x86/include/asm/ranges.h | 6 + arch/x86/include/asm/sections.h | 23 +- arch/x86/include/asm/tables.h | 6 + arch/x86/include/asm/uaccess.h | 18 +- arch/x86/kernel/cpu/microcode/core.c | 8 +- arch/x86/kernel/kprobes/core.c | 11 +- arch/x86/kernel/vmlinux.lds.S | 1 - arch/x86/tools/relocs.c | 3 + arch/xtensa/include/asm/ranges.h | 6 + arch/xtensa/include/asm/sections.h | 6 + arch/xtensa/include/asm/tables.h | 6 + drivers/base/firmware_class.c | 12 +- drivers/platform/x86/dell-smo8800.c | 1 + firmware/Makefile | 7 +- include/asm-generic/ranges.h | 70 +++ include/asm-generic/sections.h | 306 ++++++++++- include/asm-generic/tables.h | 70 +++ include/asm-generic/vmlinux.lds.h | 66 +-- include/linux/compiler.h | 2 +- include/linux/dynamic_debug.h | 5 +- include/linux/init.h | 20 +- include/linux/jump_label.h | 10 +- include/linux/kprobes.h | 8 +- include/linux/ranges.h | 54 ++ include/linux/sections.h | 123 +++++ include/linux/tables.h | 597 +++++++++++++++++++++ kernel/jump_label.c | 17 +- kernel/kprobes.c | 17 +- lib/dynamic_debug.c | 13 +- scripts/Makefile | 1 + scripts/Makefile.build | 4 +- scripts/Makefile.clean | 1 + scripts/Makefile.lib | 12 + scripts/Makefile.modpost | 2 +- scripts/mod/Makefile | 2 + scripts/mod/modpost.c | 8 +- scripts/{module-common.lds => module-common.lds.S} | 6 + scripts/recordmcount.c | 7 +- scripts/recordmcount.pl | 2 +- tools/include/linux/sections.h | 13 + tools/objtool/special.c | 8 +- 164 files changed, 2241 insertions(+), 205 deletions(-) create mode 100644 Documentation/DocBook/linker-tables.tmpl create mode 100644 Documentation/DocBook/sections.tmpl create mode 100644 arch/alpha/include/asm/ranges.h create mode 100644 arch/alpha/include/asm/sections.h create mode 100644 arch/alpha/include/asm/tables.h create mode 100644 arch/arc/include/asm/ranges.h create mode 100644 arch/arc/include/asm/tables.h create mode 100644 arch/arm/include/asm/ranges.h create mode 100644 arch/arm/include/asm/tables.h create mode 100644 arch/arm64/include/asm/ranges.h create mode 100644 arch/arm64/include/asm/sections.h create mode 100644 arch/arm64/include/asm/tables.h create mode 100644 arch/avr32/include/asm/ranges.h create mode 100644 arch/avr32/include/asm/sections.h create mode 100644 arch/avr32/include/asm/tables.h create mode 100644 arch/blackfin/include/asm/ranges.h create mode 100644 arch/blackfin/include/asm/tables.h create mode 100644 arch/c6x/include/asm/ranges.h create mode 100644 arch/c6x/include/asm/tables.h create mode 100644 arch/cris/include/asm/ranges.h create mode 100644 arch/cris/include/asm/sections.h create mode 100644 arch/cris/include/asm/tables.h create mode 100644 arch/frv/include/asm/ranges.h create mode 100644 arch/frv/include/asm/tables.h create mode 100644 arch/h8300/include/asm/ranges.h create mode 100644 arch/h8300/include/asm/sections.h create mode 100644 arch/h8300/include/asm/tables.h create mode 100644 arch/hexagon/include/asm/ranges.h create mode 100644 arch/hexagon/include/asm/sections.h create mode 100644 arch/hexagon/include/asm/tables.h create mode 100644 arch/ia64/include/asm/ranges.h create mode 100644 arch/ia64/include/asm/tables.h create mode 100644 arch/m32r/include/asm/ranges.h create mode 100644 arch/m32r/include/asm/sections.h create mode 100644 arch/m32r/include/asm/tables.h create mode 100644 arch/m68k/include/asm/ranges.h create mode 100644 arch/m68k/include/asm/sections.h create mode 100644 arch/m68k/include/asm/tables.h create mode 100644 arch/metag/include/asm/ranges.h create mode 100644 arch/metag/include/asm/sections.h create mode 100644 arch/metag/include/asm/tables.h create mode 100644 arch/microblaze/include/asm/ranges.h create mode 100644 arch/microblaze/include/asm/tables.h create mode 100644 arch/mips/include/asm/ranges.h create mode 100644 arch/mips/include/asm/sections.h create mode 100644 arch/mips/include/asm/tables.h create mode 100644 arch/mn10300/include/asm/ranges.h create mode 100644 arch/mn10300/include/asm/sections.h create mode 100644 arch/mn10300/include/asm/tables.h create mode 100644 arch/nios2/include/asm/ranges.h create mode 100644 arch/nios2/include/asm/sections.h create mode 100644 arch/nios2/include/asm/tables.h create mode 100644 arch/openrisc/include/asm/ranges.h create mode 100644 arch/openrisc/include/asm/sections.h create mode 100644 arch/openrisc/include/asm/tables.h create mode 100644 arch/parisc/include/asm/ranges.h create mode 100644 arch/parisc/include/asm/tables.h create mode 100644 arch/powerpc/include/asm/ranges.h create mode 100644 arch/powerpc/include/asm/tables.h create mode 100644 arch/s390/include/asm/ranges.h create mode 100644 arch/s390/include/asm/tables.h create mode 100644 arch/score/include/asm/ranges.h create mode 100644 arch/score/include/asm/sections.h create mode 100644 arch/score/include/asm/tables.h create mode 100644 arch/sh/include/asm/ranges.h create mode 100644 arch/sh/include/asm/tables.h create mode 100644 arch/sparc/include/asm/ranges.h create mode 100644 arch/sparc/include/asm/tables.h create mode 100644 arch/tile/include/asm/ranges.h create mode 100644 arch/tile/include/asm/tables.h create mode 100644 arch/um/include/asm/ranges.h create mode 100644 arch/um/include/asm/tables.h create mode 100644 arch/unicore32/include/asm/ranges.h create mode 100644 arch/unicore32/include/asm/sections.h create mode 100644 arch/unicore32/include/asm/tables.h create mode 100644 arch/x86/include/asm/ranges.h create mode 100644 arch/x86/include/asm/tables.h create mode 100644 arch/xtensa/include/asm/ranges.h create mode 100644 arch/xtensa/include/asm/sections.h create mode 100644 arch/xtensa/include/asm/tables.h create mode 100644 include/asm-generic/ranges.h create mode 100644 include/asm-generic/tables.h create mode 100644 include/linux/ranges.h create mode 100644 include/linux/sections.h create mode 100644 include/linux/tables.h rename scripts/{module-common.lds => module-common.lds.S} (80%) create mode 100644 tools/include/linux/sections.hSignature · 1 line
2.8.4
Signature · 1 line
Masami Hiramatsu <[email protected]>
Quoted 5 lines · Masami Hiramatsu
I'm not a lawyer, so I don't know really it is compatible with GPLv2, and if it is, I'm not sure the reason why we need another license. AFAICS the license terms, most of parts looks reasonable. I just concern clause 8, after fifteen years, is that still GPLv2 compatible? (I'd like see FAQ about this license...)
Yes, after fifteen years the restrictions in the license that make it copyleft rather than permissive disappear, and the license is transformed into a simple, essentially unconditional, permissive open source license.
Richard
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Luis R. Rodriguez
maintainerQuoted 37 lines · Masami Hiramatsu
Hi Luis,
Quoted 25 lines · On Fri, 22 Jul 2016 14:24:34 -0700 "Luis R. Rodriguez" <[email protected]>…
This RFC v3 builds off the last RFC v2 series [0] for adding linker tables. The largest amount of work here was to take Russell King's feedback on using linker table for kprobes text not being appropriate -- and providing another lightweight API for simple section ranges: read-only stitched pieces of executable code. This required also generalizing common building blocks for both linker tables and section ranges, these building blocks are defined now in
include/linux/sections.handasm-generic/section.h. The other last thing decided was to not support sub-sections. In the hunt for this I could think of anything that really required this, and if it was needed it did not seem impossible to port over to avoid its use. Please let me know if there are valid uses cases for sub-sections.Other significant effort here was to provide a set of common assembly helpers which could be used across architectures, this starts off some of this work for generic helpers which carve out and define custom Linux sections.
Lastly, this now also goes with two ports which required module support when using linker tables: jump labels, and dynamic debug support. A few extensions have been made to the original series in order to provide support for that.
Since kprobes actually had both a linker table and a section range the patch that dealt with kprobes is now split off in two patches, one that deals with its linker table and another for its section ranges.
Quoted 6 lines
More elaborate uses for linker tables are possible, I'll hold off on any of this type of work until at least the basic building blocks are fleshed out. To review how this work came about, and more elaborate uses being evaluated check out the userspace linker-tables mockup solution [1]. Hopefully most of the possible bikeshedding was already dealt with through that tree. Thanks to hpa for tons of feedback.
Quoted 2 lines
Great! so table and ranges completely replace the old-style(add-hoc)
_kprobeandNOKPROBE_SYMBOL()implementation, good job! :)
Indeed, thanks! In reality this is generalizing custom section hacks, but also making them much more powerful due to the fact that we sort now at link time, this buys us better than O(1) sort for code where dependencies can be spelled out in code, it also expands on the semantics available to us for order levels -- so we're no longer restricted to 7 levels for built-in code -- and order levels can be subject/subsystem specific.
Luis
Luis R. Rodriguez
maintainerOn Fri, Jul 22, 2016 at 02:24:34PM -0700, Luis R. Rodriguez wrote:
<-- snip -->
Quoted 41 lines
This all goes tested by 0-day... however since I found an issue with linker tables and blackfin this series remains as RFC -- I'll try to debug the issue with Steven Miao. The issue with blackfin is using a config that enables
CONFIG_FW_LOADER=yandCONFIG_DYNAMIC_DEBUG=y[5] we end up with the following at final link time:LD
init/built-in.olib/built-in.o: In function `dynamic_debug_init':
lib/dynamic_debug.c:(.init.text+0x156): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x15a): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x160): undefined reference to__verbose' lib/dynamic_debug.c:(.init.text+0x164): undefined reference to__verbose' lib/dynamic_debug.c:(.init.text+0x214): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x218): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x252): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x258): undefined reference to__verbose' lib/dynamic_debug.c:(.init.text+0x25c): undefined reference to__verbose__end' lib/dynamic_debug.c:(.init.text+0x260): undefined reference to__verbose'drivers/built-in.o: In function `release_firmware':
(.text+0x22dc2): undefined reference to `builtin_fw'drivers/built-in.o: In function `release_firmware':
(.text+0x22dc6): undefined reference tobuiltin_fw__end' drivers/built-in.o: In functionrelease_firmware':
(.text+0x22dca): undefined reference to `builtin_fw'drivers/built-in.o: In function `release_firmware':
(.text+0x22dce): undefined reference tobuiltin_fw__end' drivers/built-in.o: In functionfw_get_builtin_firmware':
drivers/base/firmware_class.c:(.text+0x23008): undefined reference tobuiltin_fw' drivers/base/firmware_class.c:(.text+0x2300c): undefined reference tobuiltin_fw__end' drivers/base/firmware_class.c:(.text+0x23010): undefined reference tobuiltin_fw' drivers/base/firmware_class.c:(.text+0x23014): undefined reference tobuiltin_fw__end' Makefile:957: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1To reproduce then:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
wget http://drvbp1.linux-foundation.org/~mcgrof/2016/07/22/blackfin-fw-dyndbg.config -o .config make.cross ARCH=blackfin
Quoted 6 lines
[0] https://lkml.kernel.org/r/[email protected]
[1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
[2] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160722-linker-table-v3-try2
[3] https://lkml.kernel.org/r/[email protected]
[4] https://lkml.kernel.org/r/[email protected]
[5] http://drvbp1.linux-foundation.org/~mcgrof/2016/07/22/blackfin-fw-dyndbg.config
Steven, curious if you've had a chance to look into this. I cannot help but suspect this is an issue of the blackfin linker as it only happens on blackfin.
Luis
Quoted 8 lines
table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
You don't need a new tag, you can use "GPL" or "GPL and additional rights". In fact you don't want any other tag because when combined with the kernel it is GPLv2 anyway because the only way the two are fully compatible is for the kernel community to license the derived work under the GPL.
The second reason you must use the GPL or GPL with additional tag is clause 8. We don't want anyone to create a module under your licence, claim it is "open source" then fifteen years later release the module in binary only form still with a tag saying "copyleft-next" which we treat as GPL compatible. It's the same reason we don't have a BSD tag but use "GPL with additional rights" to stop abuse of the module tags.
However you need to clarify the licence first I think. Linux is GPLv2, your document only allows use of GPL with "GPL" works - not GPL v2 works ?
As PS: btw your licence is kind of weird. I can combine it with GPL work, make it GPL therefore, and then use the GPL rights to remove the bits I added thereby meaning I have your exact original work under the GPL. Not sure how it's intended to work ?
It would also be good if someone clarified whether 6 and 7 are intended to combine so you can take contributed patches and put them in your own proprietary version. As a non-lawyer the intent is not clear at all.
Alan
James Bottomley
maintainerQuoted 10 lines · One Thousand Gnomes
Quoted 9 lines
table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
Quoted 5 lines
You don't need a new tag, you can use "GPL" or "GPL and additional rights". In fact you don't want any other tag because when combined
with the kernel it is GPLv2 anyway because the only way the two are
fully compatible is for the kernel community to license the derived work under the GPL.
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
Quoted 7 lines
The second reason you must use the GPL or GPL with additional tag is clause 8. We don't want anyone to create a module under your licence, claim it is "open source" then fifteen years later release the module in binary only form still with a tag saying "copyleft-next" which we treat as GPL compatible. It's the same reason we don't have a BSD tag but use "GPL with additional rights" to stop abuse of the module tags.
I don't follow you here. We do have separate Dual licence tags. Dual BSD/GPL allows me to do this today, without waiting fifteen years. I think you're conflating two issues:
1. The licence of the actual module, which must be compatible with the kernel to do an insmod. This is actually what MODULE_LICENSE declares
2. The conditions the creation of the combined work imposes on me
It's the latter, even in the case of Dual BSD/GPL which still requires me to release source code, so the combination with the kernel forces GPL conditions even in the case of a BSD module (which is otherwise compatible) and even after 15 years of this copyleft-next.
The point is: I can create a pure BSD module. You can pick it up and put it into the kernel source as Dual BSD/GPL, because BSD allows this, but I'm still free to create binary only versions under BSD (as long as they're for something other than inserting into Linux). However, if I want my binary only modules to be combined with Linux, I have to follow GPLv2 compliance because GPLv2 becomes the ruling licence of the combination. The same would apply to this copyleft-next, even after 15 years.
Quoted 3 lines
However you need to clarify the licence first I think. Linux is GPLv2, your document only allows use of GPL with "GPL" works - not GPL v2 works ?
A reasonable person would take GPL to mean any version of GPL.
Quoted 4 lines
As PS: btw your licence is kind of weird. I can combine it with GPL work, make it GPL therefore, and then use the GPL rights to remove the bits I added thereby meaning I have your exact original work under the GPL. Not sure how it's intended to work ?
What you describe is how it's always worked. You may always distribute a compatibly licensed piece of code under the stricter licence.
Additional permissions are always strippable in GPLv3 terms.
Quoted 4 lines
It would also be good if someone clarified whether 6 and 7 are intended to combine so you can take contributed patches and put them in your own proprietary version. As a non-lawyer the intent is not clear at all.
The US copyright office defines a copyright work as anything which is "an original work of authorship fixed in any tangible medium of expression". That means any change to an existing work (i.e. by a patch) which contains enough originality to make the changed work distinct from the old work is ipso facto a new work. under copyright -next this new work has a sunset 15 years from its creation by combination, not 15 years from the original. This means a constantly updated work never sunsets. Sure, you can go back 15 years and claim the code at that time has passed into the public domain but you can't do that if you also want the benefit of later changes.
James
Quoted 18 lines · James Bottomley
Quoted 10 lines · One Thousand Gnomes
Quoted 9 lines
table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
Quoted 5 lines
You don't need a new tag, you can use "GPL" or "GPL and additional rights". In fact you don't want any other tag because when combined
with the kernel it is GPLv2 anyway because the only way the two are
fully compatible is for the kernel community to license the derived work under the GPL.
Quoted 3 lines
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
Then why isn't "BSD" in the license_is_gpl_compatible list?
Quoted 4 lines
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
Because if I build a BSD licensed module against the kernel, give you the binaries and refuse to give you the source I am conforming to the BSD licence in letter. So to use it with the kernel it needs to be GPL with additional rights (eg BSD including the source...)
Alan
##SELECTION_END##
Steven Rostedt
reviewerQuoted 9 lines · On Mon, 15 Aug 2016 21:15:06 +0100 Alan Cox <[email protected]> wrote:
Quoted 3 lines
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
Because if I build a BSD licensed module against the kernel, give you the binaries and refuse to give you the source I am conforming to the BSD licence in letter. So to use it with the kernel it needs to be GPL with additional rights (eg BSD including the source...)
But that only pertains to the code that was modified to be used with the Linux kernel, right? That is, if there's a BSD licensed module for device FOO, and I port it to the Linux kernel, that will need to have a GPL added to it to be included in Linux. But the original BSD code is not affected. If a fix is made to the GPL Linux version, I'm assuming (because I've been asked when doing something like this), that the author of that fix will have to give it a dual license to be used back in the original BSD only code. Correct?
I'm just trying to understand this. From what would make sense to me (but may or may not to a court of law, where it counts), is that the code added to Linux must be under GPL. But using that code depends on where you get it from. If you use BSD source, it stays under BSD. But any fixes to the GPL version will require permission to be put back to the BSD version. A change to the GPL version doesn't automatically get allowed back to the BSD only version?
-- Steve
James Bottomley
maintainerQuoted 7 lines · Alan Cox
Quoted 3 lines
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
Because if I build a BSD licensed module against the kernel, give you the binaries and refuse to give you the source I am conforming to the BSD licence in letter.
No, you can't. Forget dual licensing for a minute: I can produce a Linux kernel module under a pure BSD licence because BSD is compatible with GPL. However, if we assume for the sake of argument that a binary module is a derived work of Linux, producing and distributing the binary for the module brings the combination under GPLv2 via the derivative works clause and I'm required to offer you corresponding source code in spite of the fact that my module *only* has a BSD licence. The only known get out from this is if I make *you* produce the binary (the open source shim defence).
Quoted 2 lines
So to use it with the kernel it needs to be GPL with additional
rights (eg BSD including the source...)
I'm not quite sure what you're disagreeing over? Is it semantics of a Dual BSD/GPL licence vs a GPL with additional rights one? Dual licensed code is a well settled area: the ruling licence is the one which permits the action. So for a dual licencesed kernel module, if I compile the module as a binary and distribute it, I'm required to follow all the provisions of GPLv2 i.e. make you and offer of
corresponding source. Conversely, if I cut and paste a section of the
driver source code into a BSD driver, I'm permitted to do this under the BSD licence, so the pasted code doesn't carry GPLv2 contamination into BSD.
You can certainly call the Dual BSD/GPL licence a GPL licence with additional permission to include the source code in a BSD licensed system, but it's not a precise equivalence because a true Dual Licensed BSD/GPL driver may be cut and pasted into any code which is compatible either with the BSD or GPL licences, meaning it's actually less strict than your additional permission to include into BSD.
James
James Bottomley
maintainerQuoted 20 lines · Andy Lutomirski
Quoted 18 lines · James Bottomley
Quoted 15 lines · One Thousand Gnomes
Quoted 9 lines
table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
You don't need a new tag, you can use "GPL" or "GPL and additional rights". In fact you don't want any other tag because when combined with the kernel it is GPLv2 anyway because the only way the two are fully compatible is for the kernel community to license the derived work under the GPL.
Quoted 5 lines
Quoted 3 lines
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
Then why isn't "BSD" in the
license_is_gpl_compatiblelist?
[Sorry about this, the list seems to have stopped sending me copies of stuff I'm on the to: line for; not sure why. Anyway, having fished this copy out of my trash:]
It is, here specifically:
https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD
James
Luis R. Rodriguez
maintainerQuoted 17 lines · James Bottomley
Quoted 10 lines · One Thousand Gnomes
Quoted 9 lines
table development go under copyleft-next, Rusty recently asked for code to go in prior to the license tag being added denoting this license as GPL-compatible [3] -- I had noted in the patch submission which annotated copyleft-next's compatibility to GPLv2 that copyleft-next is the license of choice for ongoing kernel development on my end [4]. If this is objectionable I'm happy to change it to GPLv2 however I'd like a reason provided as I've gone through all possible channels to ensure this is kosher, including vetting by 3 attorneys now, 2 at SUSE.
Quoted 5 lines
You don't need a new tag, you can use "GPL" or "GPL and additional rights". In fact you don't want any other tag because when combined
with the kernel it is GPLv2 anyway because the only way the two are
fully compatible is for the kernel community to license the derived work under the GPL.
Quoted 3 lines
This is the module tag ... it says what licence the module is under, not the licence for the module combined with the kernel, which is always GPLv2 because the stricter licence rules.
As per Linus' recommendations [0] if I add a module I'll be using MODULE_LICENSE("GPL") if using copyleft-next. Either way this series didn't add a module yet so no need for that yet, but it does use copyleft-next in headers / C code.
[0] https://lkml.kernel.org/r/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aKLsOu0Og@mail.gmail.com
Quoted 5 lines
However, if I
want my binary only modules to be combined with Linux, I have to follow GPLv2 compliance because GPLv2 becomes the ruling licence of the combination. The same would apply to this copyleft-next, even after 15 years.
And this what really matters here.
Quoted 10 lines
The US copyright office defines a copyright work as anything which is "an original work of authorship fixed in any tangible medium of expression". That means any change to an existing work (i.e. by a patch) which contains enough originality to make the changed work distinct from the old work is ipso facto a new work. under copyright -next this new work has a sunset 15 years from its creation by combination, not 15 years from the original. This means a constantly updated work never sunsets. Sure, you can go back 15 years and claim the code at that time has passed into the public domain but you can't do that if you also want the benefit of later changes.
Agreed.
Luis
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 3 lines · One Thousand Gnomes
It would also be good if someone clarified whether 6 and 7 are intended to combine so you can take contributed patches and put them in your own proprietary version. As a non-lawyer the intent is not clear at all.
6 and 7 aren't intended to combine; they address separate issues and circumstances.
Richard
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 2 lines · One Thousand Gnomes
However you need to clarify the licence first I think. Linux is GPLv2, your document only allows use of GPL with "GPL" works - not GPL v2 works ?
The license defines "GPL" as "a version of the GNU General Public License or the GNU Affero General Public License."
Richard
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel