vdso: Rename included Makefile

As the Makefile is included into other Makefiles it can not be used to
define objects to be built from the current source directory.
However the generic datastore will

vdso: Rename included Makefile

As the Makefile is included into other Makefiles it can not be used to
define objects to be built from the current source directory.
However the generic datastore will introduce such a local source file.
Rename the included Makefile so it is clear how it is to be used and to
make room for a regular Makefile in lib/vdso/.

Signed-off-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/all/[email protected]

show more ...

ARM: vdso: Remove assembly for datapage access

vdso/datapage.h provides a hidden declaration for _vdso_data.
When using it the compiler will automatically generate PC-relative
accesses which avoids

ARM: vdso: Remove assembly for datapage access

vdso/datapage.h provides a hidden declaration for _vdso_data.
When using it the compiler will automatically generate PC-relative
accesses which avoids the need for a custom assembly-based accessor.

Signed-off-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/all/[email protected]

show more ...

Makefile: remove redundant tool coverage variables

Now Kbuild provides reasonable defaults for objtool, sanitizers, and
profilers.

Remove redundant variables.

Note:

This commit changes the covera

Makefile: remove redundant tool coverage variables

Now Kbuild provides reasonable defaults for objtool, sanitizers, and
profilers.

Remove redundant variables.

Note:

This commit changes the coverage for some objects:

- include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV
- include arch/sparc/vdso/vdso-image-*.o into UBSAN
- include arch/sparc/vdso/vma.o into UBSAN
- include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
- include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
- include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV
- include arch/x86/entry/vdso/vma.o into GCOV, KCOV
- include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOV

I believe these are positive effects because all of them are kernel
space objects.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Tested-by: Roberto Sassu <[email protected]>

show more ...

kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just

kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just for copying files
to the install destination.

Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.

2. Unintended updates of in-tree build artifacts

The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").

3. Broken code in some architectures

Makefile code is often copied from one architecture to another
without proper adaptation.

'make vdso_install' for parisc does not work.

'make vdso_install' for s390 installs vdso64, but not vdso32.

To address these problems, this commit introduces a generic vdso_install
rule.

Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.

For example, arch/x86/Makefile looks like this:

vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg

These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.

vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.

The following is a snippet from arch/arm64/Makefile.

vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so

This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Sven Schnelle <[email protected]> # s390
Reviewed-by: Nicolas Schier <[email protected]>
Reviewed-by: Guo Ren <[email protected]>
Acked-by: Helge Deller <[email protected]> # parisc
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Russell King (Oracle) <[email protected]>

show more ...

vdso: Improve cmd_vdso_check to check all dynamic relocations

The actual intention is that no dynamic relocation exists in the VDSO. For
this the VDSO build validates that the resulting .so file doe

vdso: Improve cmd_vdso_check to check all dynamic relocations

The actual intention is that no dynamic relocation exists in the VDSO. For
this the VDSO build validates that the resulting .so file does not have any
relocations which are specified via $(ARCH_REL_TYPE_ABS) per architecture,
which is fragile as e.g. ARM64 lacks an entry for R_AARCH64_RELATIVE. Aside
of that ARCH_REL_TYPE_ABS is a misnomer as it checks for relative
relocations too.

However, some GNU ld ports produce unneeded R_*_NONE relocation entries. If
a port fails to determine the exact .rel[a].dyn size, the trailing zeros
become R_*_NONE relocations. E.g. ld's powerpc port recently fixed
https://sourceware.org/bugzilla/show_bug.cgi?id=29540). R_*_NONE are
generally a no-op in the dynamic loaders. So just ignore them.

Remove the ARCH_REL_TYPE_ABS defines and just validate that the resulting
.so file does not contain any R_* relocation entries except R_*_NONE.

Signed-off-by: Fangrui Song <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Vincenzo Frascino <[email protected]> # for aarch64
Reviewed-by: Christophe Leroy <[email protected]>
Reviewed-by: Vincenzo Frascino <[email protected]> # for vDSO, aarch64
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Link: https://lore.kernel.org/r/[email protected]

show more ...

ARM: 9253/1: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on ARM, this patch enables ARCH_HAS_UBSAN_SANITIZE_ALL
from arm confiuration. Basic kernel bootup test is passed on arm with
CO

ARM: 9253/1: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on ARM, this patch enables ARCH_HAS_UBSAN_SANITIZE_ALL
from arm confiuration. Basic kernel bootup test is passed on arm with
CONFIG_UBSAN_SANITIZE_ALL enabled.

[florian: rebased against v6.0-rc7]

Signed-off-by: Seung-Woo Kim <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

randstruct: Split randstruct Makefile and CFLAGS

To enable the new Clang randstruct implementation[1], move
randstruct into its own Makefile and split the CFLAGS from
GCC_PLUGINS_CFLAGS into RANDSTR

randstruct: Split randstruct Makefile and CFLAGS

To enable the new Clang randstruct implementation[1], move
randstruct into its own Makefile and split the CFLAGS from
GCC_PLUGINS_CFLAGS into RANDSTRUCT_CFLAGS.

[1] https://reviews.llvm.org/D121556

Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

ARM: 9181/1: vdso: remove -nostdlib compiler flag

The -nostdlib option requests the compiler to not use the standard
system startup files or libraries when linking. It is effective only
when $(CC) i

ARM: 9181/1: vdso: remove -nostdlib compiler flag

The -nostdlib option requests the compiler to not use the standard
system startup files or libraries when linking. It is effective only
when $(CC) is used as a linker driver.

Since commit fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of
$(CC) to link VDSO"), $(LD) is directly used, hence -nostdlib is
unneeded.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9051/1: vdso: remove unneded extra-y addition

The vdso linker script is prepocessed on demand. Adding it to 'targets'
is enough, and line 13 of this Makefile does that. This extra-y addition
is

ARM: 9051/1: vdso: remove unneded extra-y addition

The vdso linker script is prepocessed on demand. Adding it to 'targets'
is enough, and line 13 of this Makefile does that. This extra-y addition
is unneeded.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 9013/2: Disable KASan instrumentation for some code

Disable instrumentation for arch/arm/boot/compressed/*
since that code is executed before the kernel has even
set up its mappings and definat

ARM: 9013/2: Disable KASan instrumentation for some code

Disable instrumentation for arch/arm/boot/compressed/*
since that code is executed before the kernel has even
set up its mappings and definately out of scope for
KASan.

Disable instrumentation of arch/arm/vdso/* because that code
is not linked with the kernel image, so the KASan management
code would fail to link.

Disable instrumentation of arch/arm/mm/physaddr.c. See commit
ec6d06efb0ba ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
for more details.

Disable kasan check in the function unwind_pop_register because
it does not matter that kasan checks failed when unwind_pop_register()
reads the stack memory of a task.

Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: [email protected]
Reviewed-by: Ard Biesheuvel <[email protected]>
Tested-by: Ard Biesheuvel <[email protected]> # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli <[email protected]> # Brahma SoCs
Tested-by: Ahmad Fatoum <[email protected]> # i.MX6Q
Reported-by: Florian Fainelli <[email protected]>
Reported-by: Marc Zyngier <[email protected]>
Signed-off-by: Abbott Liu <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

kbuild: explicitly specify the build id style

ld's --build-id defaults to "sha1" style, while lld defaults to "fast".
The build IDs are very different between the two, which may confuse
programs tha

kbuild: explicitly specify the build id style

ld's --build-id defaults to "sha1" style, while lld defaults to "fast".
The build IDs are very different between the two, which may confuse
programs that reference them.

Signed-off-by: Bill Wendling <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

ARM: vdso: Don't use gcc plugins for building vgettimeofday.c

Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
avoid unneeded instrumentation. As previously discussed[1]:

arm_ssp

ARM: vdso: Don't use gcc plugins for building vgettimeofday.c

Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
avoid unneeded instrumentation. As previously discussed[1]:

arm_ssp_per_task_plugin.c
32-bit ARM only (but likely needs disabling for 32-bit ARM vDSO?)

cyc_complexity_plugin.c
compile-time reporting only

latent_entropy_plugin.c
this shouldn't get triggered for the vDSO (no __latent_entropy
nor __init attributes in vDSO), but perhaps explicitly disabling
it would be a sensible thing to do, just for robustness?

randomize_layout_plugin.c
this shouldn't get triggered (again, lacking attributes), but
should likely be disabled too.

sancov_plugin.c
This should be tracking the KCOV directly (see
scripts/Makefile.kcov), which is already disabled here.

structleak_plugin.c
This should be fine in the vDSO, but there's no security
boundary here, so it wouldn't be important to KEEP it enabled.

[1] https://lore.kernel.org/lkml/20200610073046.GA15939@willie-the-truck/

Signed-off-by: Alexander Popov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>

show more ...

kbuild: rename hostprogs-y/always to hostprogs/always-y

In old days, the "host-progs" syntax was used for specifying host
programs. It was renamed to the current "hostprogs-y" in 2004.

It is typica

kbuild: rename hostprogs-y/always to hostprogs/always-y

In old days, the "host-progs" syntax was used for specifying host
programs. It was renamed to the current "hostprogs-y" in 2004.

It is typically useful in scripts/Makefile because it allows Kbuild to
selectively compile host programs based on the kernel configuration.

This commit renames like follows:

always -> always-y
hostprogs-y -> hostprogs

So, scripts/Makefile will look like this:

always-$(CONFIG_BUILD_BIN2C) += ...
always-$(CONFIG_KALLSYMS) += ...
...
hostprogs := $(always-y) $(always-m)

I think this makes more sense because a host program is always a host
program, irrespective of the kernel configuration. We want to specify
which ones to compile by CONFIG options, so always-y will be handier.

The "always", "hostprogs-y", "hostprogs-m" will be kept for backward
compatibility for a while.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

ARM: vdso: Set BUILD_VDSO32 and provide 32bit fallbacks

Setting BUILD_VDSO32 is required to expose the legacy 32bit interfaces in
the generic VDSO code which are going to be hidden behind an #ifdef

ARM: vdso: Set BUILD_VDSO32 and provide 32bit fallbacks

Setting BUILD_VDSO32 is required to expose the legacy 32bit interfaces in
the generic VDSO code which are going to be hidden behind an #ifdef
BUILD_VDSO32.

The 32bit fallbacks are necessary to remove the existing
VDSO_HAS_32BIT_FALLBACK hackery.

Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Vincenzo Frascino <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]

show more ...

ARM: 8930/1: Add support for generic vDSO

The arm vDSO library requires some adaptations to take advantage of
the newly introduced generic vDSO library.

Introduce the following changes:
- Modifica

ARM: 8930/1: Add support for generic vDSO

The arm vDSO library requires some adaptations to take advantage of
the newly introduced generic vDSO library.

Introduce the following changes:
- Modification vdso.c to be compliant with the common vdso datapage
- Use of lib/vdso for gettimeofday
- Implementation of elf note

Signed-off-by: Vincenzo Frascino <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

kbuild: add --hash-style= and --build-id unconditionally

As commit 1e0221374e30 ("mips: vdso: drop unnecessary cc-ldoption")
explained, these flags are supported by the minimal required version
of b

kbuild: add --hash-style= and --build-id unconditionally

As commit 1e0221374e30 ("mips: vdso: drop unnecessary cc-ldoption")
explained, these flags are supported by the minimal required version
of binutils. They are supported by ld.lld too.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>

show more ...

ARM: 8860/1: VDSO: Drop implicit common-page-size linker flag

GNU linker's -z common-page-size's default value is based on the target
architecture. arch/arm/vdso/Makefile sets it to the architecture

ARM: 8860/1: VDSO: Drop implicit common-page-size linker flag

GNU linker's -z common-page-size's default value is based on the target
architecture. arch/arm/vdso/Makefile sets it to the architecture
default, which is implicit and redundant. Drop it.

Link: https://lkml.kernel.org/r/[email protected]

Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Nathan Lynch <[email protected]>
Suggested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8867/1: vdso: pass --be8 to linker if necessary

The commit fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC)
to link VDSO") removed the passing of CFLAGS, since ld doesn't take
those

ARM: 8867/1: vdso: pass --be8 to linker if necessary

The commit fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC)
to link VDSO") removed the passing of CFLAGS, since ld doesn't take
those directly. However, prior, big-endian ARM was relying on gcc to
translate its -mbe8 option into ld's --be8 option. Lacking this, ld
generated be32 code, making the VDSO generate SIGILL when called by
userspace.

This commit passes --be8 if CONFIG_CPU_ENDIAN_BE8 is enabled.

Signed-off-by: Jason A. Donenfeld <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO

We use $(LD) to link vmlinux, modules, decompressors, etc.

VDSO is the only exceptional case where $(CC) is used as the linker
driver, but

ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO

We use $(LD) to link vmlinux, modules, decompressors, etc.

VDSO is the only exceptional case where $(CC) is used as the linker
driver, but I do not know why we need to do so. VDSO uses a special
linker script, and does not link standard libraries at all.

I changed the Makefile to use $(LD) rather than $(CC). I confirmed
the same vdso.so.raw was still produced.

Users will be able to use their favorite linker (e.g. lld instead of
of bfd) by passing LD= from the command line.

My plan is to rewrite all VDSO Makefiles to use $(LD), then delete

cc-ldoption.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

arm: port KCOV to arm

KCOV is code coverage collection facility used, in particular, by
syzkaller system call fuzzer. There is some interest in using syzkaller
on arm devices. So port KCOV to arm.

arm: port KCOV to arm

KCOV is code coverage collection facility used, in particular, by
syzkaller system call fuzzer. There is some interest in using syzkaller
on arm devices. So port KCOV to arm.

On implementation level this merely declares that KCOV is supported and
disables instrumentation of 3 special cases. Reasons for disabling are
commented in code.

Tested with qemu-system-arm/vexpress-a15.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Dmitry Vyukov <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Cc: Russell King <[email protected]>
Cc: Abbott Liu <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Koguchi Takuo <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

kbuild: drop FORCE from PHONY targets

These targets are marked as PHONY. No need to add FORCE to their
dependency.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Mic

kbuild: drop FORCE from PHONY targets

These targets are marked as PHONY. No need to add FORCE to their
dependency.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable

The Sourcery CodeBench Lite 2014.05 toolchain (gcc 4.8.3, binutils
2.24.51) has a GCC which implements -fuse-ld, and it do

ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable

The Sourcery CodeBench Lite 2014.05 toolchain (gcc 4.8.3, binutils
2.24.51) has a GCC which implements -fuse-ld, and it doesn't include
the gold linker, but it lacks an ld.bfd executable in its
installation. This means that passing -fuse-ld=bfd fails with:

VDSO arch/arm/vdso/vdso.so.raw
collect2: fatal error: cannot find 'ld'

Arguably this is a deficiency in the toolchain, but I suspect it's
commonly used enough that it's worth accommodating: just use

cc-ldoption (to cause a link attempt) instead of cc-option to test
whether we can use -fuse-ld. So -fuse-ld=bfd won't be used with this
toolchain, but the build will rightly succeed, just as it does for
toolchains which don't implement -fuse-ld (and don't use gold as the
default linker).

Note: this will change the failure mode for a corner case I was trying
to handle in d2b30cd4b722, where the toolchain defaults to the gold
linker and the BFD linker is not found in PATH, from:

VDSO arch/arm/vdso/vdso.so.raw
collect2: fatal error: cannot find 'ld'

i.e. the BFD linker is not found, to:

OBJCOPY arch/arm/vdso/vdso.so
BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
linking with -N

that is, we fail to prevent gold from being used as the linker, and it
produces an object that objcopy can't digest.

Reported-by: Baruch Siach <[email protected]>
Tested-by: Baruch Siach <[email protected]>
Tested-by: Raphaël Poggi <[email protected]>
Fixes: d2b30cd4b722 ("ARM: 8384/1: VDSO: force use of BFD linker")
Cc: [email protected]
Signed-off-by: Nathan Lynch <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8384/1: VDSO: force use of BFD linker

When using a toolchain with gold as the default linker, the VDSO build
fails:

VDSO arch/arm/vdso/vdso.so.raw
HOSTCC arch/arm/vdso/vdsomunge
MUNG

ARM: 8384/1: VDSO: force use of BFD linker

When using a toolchain with gold as the default linker, the VDSO build
fails:

VDSO arch/arm/vdso/vdso.so.raw
HOSTCC arch/arm/vdso/vdsomunge
MUNGE arch/arm/vdso/vdso.so.dbg
OBJCOPY arch/arm/vdso/vdso.so
BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
linking with -N

For whatever reason, ld.gold is omitting an exidx program header that
ld.bfd emits, and even when I work around that, I don't get a working
VDSO.

For now, instead of supporting gold (which will fail to link the
kernel anyway since it does not implement --pic-veneer), direct the
compiler to use the traditional bfd linker. This is accomplished by
using -fuse-ld, which is implemented in GCC 4.8 and later.

Note: one limitation of this is that if the toolchain is configured
to use gold by default, and the bfd linker is not in $PATH, the VDSO
build will fail:

VDSO arch/arm/vdso/vdso.so.raw
collect2: fatal error: cannot find 'ld'

This will happen if CROSS_COMPILE begins with a path such as
/opt/bin/arm-linux-gnu- but /opt/bin is not in $PATH. This is
considered an acceptable corner-case limitation and is easily worked
around.

Additonal note: we use cc-option instead of cc-ldoption so that
-fuse-ld=bfd is placed in the command line if the compiler recognizes
the option. Using cc-ldoption results in an attempt to link, which
fails in the situation just described, causing -fuse-ld=bfd to be
omitted and gold to be used for the VDSO link, which is what we're
trying to prevent.

Reported-by: Stefan Agner <[email protected]>
Signed-off-by: Nathan Lynch <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8385/1: VDSO: group link options

Currently the VDSO's link options are kind of a mess spread between

ccflags-y and cmd_vdsold. Collect linker directives into one
variable, VDSO_LDFLAGS, and u

ARM: 8385/1: VDSO: group link options

Currently the VDSO's link options are kind of a mess spread between

ccflags-y and cmd_vdsold. Collect linker directives into one
variable, VDSO_LDFLAGS, and use that in cmd_vdsold.

Signed-off-by: Nathan Lynch <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...