linux.git/include/asm-generic/export.h, branch v6.6.131

ia64,export.h: replace EXPORT_DATA_SYMBOL* with EXPORT_SYMBOL*

2023-06-22T12:21:06+00:00

With the previous refactoring, you can always use EXPORT_SYMBOL*.

Replace two instances in ia64, then remove EXPORT_DATA_SYMBOL*.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nick Desaulniers

kbuild: generate KSYMTAB entries by modpost

2023-06-22T12:17:10+00:00

Commit 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing
CONFIG_MODULE_REL_CRCS") made modpost output CRCs in the same way
whether the EXPORT_SYMBOL() is placed in *.c or *.S.

For further cleanups, this commit applies a similar approach to the
entire data structure of EXPORT_SYMBOL().

The EXPORT_SYMBOL() compilation is split into two stages.

When a source file is compiled, EXPORT_SYMBOL() will be converted into
a dummy symbol in the .export_symbol section.

For example,

    EXPORT_SYMBOL(foo);
    EXPORT_SYMBOL_NS_GPL(bar, BAR_NAMESPACE);

will be encoded into the following assembly code:

    .section ".export_symbol","a"
    __export_symbol_foo:
            .asciz ""                      /* license */
            .asciz ""                      /* name space */
            .balign 8
            .quad foo                      /* symbol reference */
    .previous

    .section ".export_symbol","a"
    __export_symbol_bar:
            .asciz "GPL"                   /* license */
            .asciz "BAR_NAMESPACE"         /* name space */
            .balign 8
            .quad bar                      /* symbol reference */
    .previous

They are mere markers to tell modpost the name, license, and namespace
of the symbols. They will be dropped from the final vmlinux and modules
because the *(.export_symbol) will go into /DISCARD/ in the linker script.

Then, modpost extracts all the information about EXPORT_SYMBOL() from the
.export_symbol section, and generates the final C code:

    KSYMTAB_FUNC(foo, "", "");
    KSYMTAB_FUNC(bar, "_gpl", "BAR_NAMESPACE");

KSYMTAB_FUNC() (or KSYMTAB_DATA() if it is data) is expanded to struct
kernel_symbol that will be linked to the vmlinux or a module.

With this change, EXPORT_SYMBOL() works in the same way for *.c and *.S
files, providing the following benefits.

[1] Deprecate EXPORT_DATA_SYMBOL()

In the old days, EXPORT_SYMBOL() was only available in C files. To export
a symbol in *.S, EXPORT_SYMBOL() was placed in a separate *.c file.
arch/arm/kernel/armksyms.c is one example written in the classic manner.

Commit 22823ab419d8 ("EXPORT_SYMBOL() for asm") removed this limitation.
Since then, EXPORT_SYMBOL() can be placed close to the symbol definition
in *.S files. It was a nice improvement.

However, as that commit mentioned, you need to use EXPORT_DATA_SYMBOL()
for data objects on some architectures.

In the new approach, modpost checks symbol's type (STT_FUNC or not),
and outputs KSYMTAB_FUNC() or KSYMTAB_DATA() accordingly.

There are only two users of EXPORT_DATA_SYMBOL:

  EXPORT_DATA_SYMBOL_GPL(empty_zero_page)    (arch/ia64/kernel/head.S)
  EXPORT_DATA_SYMBOL(ia64_ivt)               (arch/ia64/kernel/ivt.S)

They are transformed as follows and output into .vmlinux.export.c

  KSYMTAB_DATA(empty_zero_page, "_gpl", "");
  KSYMTAB_DATA(ia64_ivt, "", "");

The other EXPORT_SYMBOL users in ia64 assembly are output as
KSYMTAB_FUNC().

EXPORT_DATA_SYMBOL() is now deprecated.

[2] merge  and 

There are two similar header implementations:

  include/linux/export.h        for .c files
  include/asm-generic/export.h  for .S files

Ideally, the functionality should be consistent between them, but they
tend to diverge.

Commit 8651ec01daed ("module: add support for symbol namespaces.") did
not support the namespace for *.S files.

This commit shifts the essential implementation part to C, which supports
EXPORT_SYMBOL_NS() for *.S files.

 and  will remain as a wrapper of
 for a while.

They will be removed after #include  directives are all
replaced with #include .

[3] Implement CONFIG_TRIM_UNUSED_KSYMS in one-pass algorithm (by a later commit)

When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
the directory tree to determine which EXPORT_SYMBOL to trim. If an
EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the
second traverse, where some source files are recompiled with their
EXPORT_SYMBOL() tuned into a no-op.

We can do this better now; modpost can selectively emit KSYMTAB entries
that are really used by modules.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nick Desaulniers

kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS

2022-05-24T07:33:20+00:00

include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.

Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.

It is time to get rid of this complexity.

Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.

Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.

Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.

No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.

Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.

Signed-off-by: Masahiro Yamada 
Tested-by: Nathan Chancellor 
Tested-by: Nicolas Schier 
Reviewed-by: Nicolas Schier 
Tested-by: Sedat Dilek  # LLVM-14 (x86-64)

asm-generic: export: Stub EXPORT_SYMBOL with __DISABLE_EXPORTS

2021-02-03T16:42:57+00:00

It is currently possible to stub EXPORT_SYMBOL() macros in C code using
__DISABLE_EXPORTS, which is necessary to run in constrained environments
such as the EFI stub or the decompressor. But this currently doesn't
apply to exports from assembly, which can lead to somewhat confusing
situations.

Consolidate the __DISABLE_EXPORTS infrastructure by checking it from
asm-generic/export.h as well.

Signed-off-by: Quentin Perret 
Acked-by: Will Deacon 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20210203141931.615898-2-qperret@google.com

export.h: reduce __ksymtab_strings string duplication by using "MS" section flags

2019-12-16T09:35:33+00:00

Commit c3a6cf19e695 ("export: avoid code duplication in
include/linux/export.h") refactors export.h quite nicely, but introduces
a slight increase in memory usage due to using the empty string ""
instead of NULL to indicate that an exported symbol has no namespace. As
mentioned in that commit, this meant an increase of 1 byte per exported
symbol without a namespace. For example, if a kernel configuration has
about 10k exported symbols, this would mean that the size of
__ksymtab_strings would increase by roughly 10kB.

We can alleviate this situation by utilizing the SHF_MERGE and
SHF_STRING section flags. SHF_MERGE|SHF_STRING indicate to the linker
that the data in the section are null-terminated strings that can be
merged to eliminate duplication. More specifically, from the binutils
documentation - "for sections with both M and S, a string which is a
suffix of a larger string is considered a duplicate. Thus "def" will be
merged with "abcdef"; A reference to the first "def" will be changed to
a reference to "abcdef"+3". Thus, all the empty strings would be merged
as well as any strings that can be merged according to the cited method
above. For example, "memset" and "__memset" would be merged to just
"__memset" in __ksymtab_strings.

As of v5.4-rc5, the following statistics were gathered with x86
defconfig with approximately 10.7k exported symbols.

Size of __ksymtab_strings in vmlinux:
-------------------------------------
v5.4-rc5: 213834 bytes
v5.4-rc5 with commit c3a6cf19e695: 224455 bytes
v5.4-rc5 with this patch: 205759 bytes

So, we already see memory savings of ~8kB compared to vanilla -rc5 and
savings of nearly 18.7kB compared to -rc5 with commit c3a6cf19e695 on top.

Unfortunately, as of this writing, strings will not get deduplicated for
kernel modules, as ld does not do the deduplication for
SHF_MERGE|SHF_STRINGS sections for relocatable files (ld -r), which
kernel modules are. A patch for ld is currently being worked on to
hopefully allow for string deduplication in relocatable files in the
future.

Suggested-by: Rasmus Villemoes 
Reviewed-by: Masahiro Yamada 
Reviewed-by: Matthias Maennich 
Signed-off-by: Jessica Yu

Merge tag 'spdx-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx

2019-12-03T22:20:21+00:00

Pull SPDX fix from Greg KH:
 "Here is a single SPDX fixup for 5.5-rc1

  It resolves an issue where we had missed a few .h files with the
  auto-tagging scripts because they had "GPL" text in strings within the
  file themselves. This single patch fixes up the issue and provides the
  proper SPDX tags at the top of them as needed.

  This patch has been in linux-next for many many weeks now with no
  reported issues"

* tag 'spdx-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx:
  export,module: add SPDX GPL-2.0 license identifier to headers with no license

export,module: add SPDX GPL-2.0 license identifier to headers with no license

2019-11-14T03:36:53+00:00

Commit b24413180f56 ("License cleanup: add SPDX GPL-2.0 license
identifier to files with no license") took care of a lot of files
without any license information.

These headers were not processed by the tool perhaps because they
contain "GPL" in the code.

I do not see any license boilerplate in them, so they fall back to
GPL version 2 only, which is the project default.

Signed-off-by: Masahiro Yamada 
Link: https://lore.kernel.org/r/20191018045053.8424-1-yamada.masahiro@socionext.com
Signed-off-by: Greg Kroah-Hartman

asm-generic/export.h: remove unneeded __kcrctab_* symbols

2019-11-11T11:10:01+00:00

EXPORT_SYMBOL from assembly code produces an unused symbol __kcrctab_*.

kcrctab is used as a section name (prefixed with three underscores),
but never used as a symbol.

Signed-off-by: Masahiro Yamada

asm-generic/export.h: make __ksymtab_* local symbols

2019-11-11T11:10:01+00:00

For EXPORT_SYMBOL from C files,  defines __ksymtab_*
as local symbols.

For EXPORT_SYMBOL from assembly, in contrast, 
produces globally-visible __ksymtab_* symbols due to this .globl
directive.

I do not know why this must be global. It still works without this.

Signed-off-by: Masahiro Yamada

module: Remove leftover '#undef' from export header

2019-09-12T13:29:46+00:00

Commit 7290d5809571 ("module: use relative references for __ksymtab
entries") converted the '__put' #define into an assembly macro in
asm-generic/export.h but forgot to remove the corresponding '#undef'.

Remove the leftover '#undef'.

Cc: Ard Biesheuvel 
Cc: Jessica Yu 
Signed-off-by: Will Deacon 
Signed-off-by: Jessica Yu